Btrfs on Fedora

When I first started using Fedora WS back at F16 time. One of the things I asked about was disk defrag tools. I was told that ext4 didn’t need them and was shown the details of why. I was really happy about that. Disk maintenance was just another unloved task I was glad to be rid of. Over the years since I’ve never had to do any disk maintenance in the six month period between releases. I should say I always do bare metal installs reclaiming all disk space then restore the home directories.

Yesterday, in light of the btrfs proposal for F33, I installed rawhide F33 WS with btrfs to try it out and run some tests. Generally, so far, it seems fine, I can see the advantages btrfs brings and welcome them.

However, when I was done with my try out. I started reading through the associated man pages and those for the btrfs tool packages. Wow! it seems like I’m back in the disk maintenance business. All the tools seem to be command line so there’s lots of new disk maintenance commands, filters, qualifiers, etc to learn. Also writing the scripts, scheduling them and maintaining them. The script I run to set up a PC removes and installs about 70 packages. I’m guessing that the btrfs on my test machine is full of holes and that will lead to file fragmentation and other miseries.

I’m hoping some will tell me I’m wrong, but in case I’m not I know that I would appreciate it a lot if there was some tools or doc’s that would help with getting the disk maintenance set up. At least for me, setting up something like this with only man pages to guide me is a long nasty process.

Hi tablepc:

File fragmentation is a known problem for log-structured file systems on magnetic media. If you are using a magnetic/rotational hard disk drive, btrfs may not be the best choice performance wise. File fragmentation should not be a concern on SSDs, however. If you are using an SSD, then I would say benefits far out way the costs.

Don’t (regularly) defragment file systems stored on SSDs. Doing so only causes excessive wear on them and shortens their lifespan.

All the systems here use magnetic rotational hard disks. Changing everything to SSDs won’t be possible. I guess if btrfs gets to be the default, I’ll be hoping that ext4 is one of the options on the “Custom” storage setup in Anaconda. That will give me some room to figure out the disk maintenance stuff for btrfs.

ext4 isn’t going anywhere. It’s unfortunate that they’re considering changing
defaults to something you’d expect in 1995, with the instability of the
filesystem as well (multiple people on the Fedora mailing lists, myself
included, have tested btrfs several times over the years, and run into data
loss).

I had trouble with btrfs as well, but it was many years ago when it first came out and I was under the impression that things were better now. I don’t know personally. After my experiences with btrfs, I switched to ZFS which I’ve been using for many years and have been very happy with. I can definitely attest that log-based file systems can be absolutely amazing in terms of what they can do. But I cannot really speak to btrfs’ current state.

Either way though – ZFS or btrfs – I wouldn’t recommend using them on rotational disks.

Well, my report on using btrfs with Fedora is different. I have been using btrfs since Fedora 25, and I have not had a single issue that I would blame on btrfs.

But yes, I maintain my filesystem on a weekly basis. I create read-only snapshots of my subvolumes and send them to an external drive. I balance it with -dusage=85, then I scrub it. This is just a personal use notebook PC, so all of this takes only a few minutes, once per week.

To me, the big advantages of btrfs are integrated volume management and blazing fast snapshots.

A number of rituals have developed over the years, due to real bugs in space management on Btrfs. The most significant change happened in 2016, the “ticketed enospc infrastructure”.

My suggestion is to not do these rituals anymore. I don’t babysit my Btrfs file systems, whether on HDD or SSD. I don’t expect other folks should need to either. If there are edge cases where there is poor performance, they need to be reported as bugs/enhancements - and yeah in that case, maybe we end up with new rituals to alleviate the problem in the short term. But those mitigations should be automatic, and specific to rotational drives.

It is true that Btrfs lacks many of the locality optimizations ext4 and XFS have, based on rotating media. What it does instead is make heavy use of delayed allocation so that small random writes turn into more sequential writes. And also inline extents, where small files are included in the 16KiB (default size) metadata block along with the file inode. My opinion is if you have to do maintenance rituals to maintain performance, the file system needs optimization to fix it, not user initiated maintenance rituals.

It’s completely reasonable to continue to use ext4 or XFS if you prefer it. And yes that will still be a custom partitioning install time option for the foreseeable future.

2 Likes