Chris's Wiki :: blog/linux/Ext4RootFilesystemWhy

Why I (still) use ext4 for my Linux root filesystems

December 31, 2021

In a comment on my entry on checking what ext4 features your filesystem has, I was asked why I still use ext4 for my root filesystem, when CentOS changed to xfs by default and Fedora changed to btrfs (Fedora may have defaulted to xfs for the root filesystem for a while, I'm not sure). There are three answers to this, especially for btrfs.

The technical answer is that for my root filesystem I don't need any of the extra features that XFS or especially btrfs bring to the table. My root filesystem is just for system things, for RPMs and so on; it doesn't hold any user data (apart, arguably, from logs) and it doesn't do anything demanding. Both XFS and btrfs have advanced capabilities but my root filesystem doesn't particularly benefit from them. And for btrfs in specific, to take advantage of some of its capabilities in my usual mirrored system disks setup I would have to change to using btrfs's native mirroring instead of software RAID mirroring.

The practical answer is that I know much more about managing and troubleshooting ext4 (and software RAID mirrors) than I do about either XFS or especially btrfs. It's easier for me to create and operate ext4 filesystems on top of software RAID mirrors, and I have a high confidence that I know how to recover from problems in one way or another. My most recent XFS experience is on actual SGI hardware and I have no real btrfs experience.

(It turns out that one of my Fedora VMs is recent enough that its root filesystem is btrfs, but the fact that I didn't know this until I checked now shows how much experience I have with it.)

The general answer is that I don't trust XFS (on Linux) or especially btrfs with its own mirroring half as much as I trust ext4 on software RAID. The very last thing I want for my root filesystem is for it to be exciting, and I have a much higher confidence that ext4 will be very boring. I'm sure that XFS and even btrfs generally run fine (certainly Fedora has not been deluged by reports that btrfs root filesystems have problems), but I still prefer the conservative, boring, and extremely well tested ext4 option.

(The very boring answer for why my home desktop's root filesystem is ext4 right now is that it didn't occur to me to make it any other filesystem type when I created it by hand in early 2017 as part of migrating my root filesystem to these SSDs.)

Sidebar: I'm not interested in snapshots for system upgrades

One of the great white promises of using filesystems like btrfs or ZFS for your root filesystem is taking snapshots before upgrades and rapidly rolling back if something goes wrong. I'm not particularly interested in this. I don't expect it to work as well as you'd like in practice for reasons beyond the scope of this entry, and I do expect it to need a huge amount of extra disk space in the case of major upgrades like moving from Fedora version to Fedora version, since Fedora rebuilds all of its RPMs (which changes many binaries at least).

For smaller upgrades like upgrading some RPMs, the existing approaches of things like reinstalling the old RPMs to roll back work fine for me on the rare occasions when I need them.

Comments on this page:

By Aristotle Pagaltzis at 2022-01-01 07:47:45:

I don't expect it to work as well as you'd like in practice for reasons beyond the scope of this entry

I’d love to read an entry whose scope is those reasons.

By Michael Kohne at 2022-01-01 09:00:21:

   I’d love to read an entry whose scope is those reasons.
I don't know about Chris, but for me (with a bunch of experience snapshotting VMs pre-upgrade), a pre-upgrade snapshot is only really good for 'oh, that made it completely not boot', which should be a pretty rare occurrence normally.

The problem is that a snapshot is, well, a snapshot. Once you've gotten past the upgrade and started doing work again, returning to a previous snapshot becomes a non-option because you'll lose things you've done since then. Some of which you probably won't remember you've done. At that point, you're going to want to debug and fix, rather than try to fall back to previous state.

There are, of course, exceptions to this (that machine that just services the antique fax-modem? Yea, snapshot and rollback if it goes to hell).

By Jason at 2022-01-01 11:06:43:

I generally use ext4 for the root filesystem on virtualized systems because using a non-COW filesystem saves space in the backup snapshots. However, I have no fear of Btrfs when it's running in a mirrored configuration. I have been using it for years as the root filesystem on multiple systems that contain multiple subvolumes and snapshots, and it has always been rock solid. Keeping snapshots of the root filesystem is hugely valuable for me. I rollback the root even for the simplest things such as trying new software that I decide I don't need. I use Snapper to take the snapshots, and to rollback I use my own script. The script renames the active root subvolume, creates a new root subvolume from a snapshot, sets the new root subvolume as the default and restores the boot files for that snapshot. Just one quick reboot and I'm up on the old snapshot, then I run a different script to delete the old root subvolume. It would also be possible to use Btrfs send/receive to transfer the root filesystem to a different drive.

By Ben Cotton at 2022-01-02 13:25:41:

I'll probably keep using ext4 on my server indefinitely. Mostly because I know the ext4/lvm/mdadm stack well enough for my needs that making a change seems like an unnecessary risk. On my laptops, I'll go with the BTRFS default on new installs because why not? I don't do anything particularly interesting with laptop drives to begin with, and all of the important stuff lives on the server or in an Ansible playbook.

Written on 31 December 2021.

«	Checking what features your ext4 filesystems have

Why I'm not interested in rolling back to snapshots of Linux root filesystems