Do I need to be the nanny for my btrfs file system?

Hi there!

I installed Fedora 39 recently, and I want to do as less maintenance as possible. I want a laptop that just works and a system that runs. I do software updates but besides this I dont want to be bothered by my system.

Today I read here that there are maintenance recommendations for btrfs file systems. The comment there talks about scrub and unallocated space, which needs to be dealt with by running certain commands.

Now, here’s my question: Do I need to care about those things? I don’t want to nanny my filesystem. I want it to work without maintenance (like ext4) and not forcing me to keep track of cleaning commands and whatnot.

Are the linked recommendations exaggerations or does btrfs really need this kind of attention?

1 Like

Interesting question.

It seems that btrfs scrub will only report errors if you are not using RAID, is that right?
That’s better then EXT4 that cannot spot metadata errors.

On my 2TiB btrfs volume I’m seeing lots and lots of unallocated space so no need
to run the btrfs balance.

So it looks like there is no need to run these things in normal use.

There are some things that can be optionally done to prevent mild degradation over time. Whether or not you would notice the impact of doing them or not depends a lot on your hardware and usage, but if you want to do those things and think less about them, then btrfs-assistant is a useful tool and is in the Fedora repo tools. I wouldn’t be opposed to this being included by default in Workstation, etc.

It’s not that I want to do those things. The question is do I need to do those things occasionally and what happens if I don’t do them?

As for the hardware, I only run a laptop with a SSD and Fedora 39 on it.

The quality of the SSD is the key factor for reliability.
I look at the “write endurance” of SSD drives when selecting one.
That figure tells you how much data can be written before the drive is likely to fail.
The higher the less likely it will fail.

Added btrfs

Here’s the thing - I’ve been running btrfs since around 2015 and I didn’t know that I was supposed to be doing scrub and balance until a few months ago. I hadn’t been doing them and I didn’t notice any problem with not doing them. That’s across various different installs and SSD manufacturers. So, technically, there is some small potential benefit to doing them, but it’s not like forgetting to change your air filter so your heater caught fire type of situation. I haven’t had an SSD premature fail over it, nor do I think that is a remotely likely risk. What happens if you don’t do them is you might have eventual mild performance degradation. Enough that you would notice for normal laptop workloads? Probably not.

I suggest doing one of two things:

  • Install btrfs assistant and set it to happen automatically using the defaults there
  • Do nothing and keep using your system as you have been

You don’t need to run maintenance. There’s a vanishingly small chance of an edge case (bug) related to free space you could run into, and that a regularly scheduled filtered balance would prevent.

The package btrfs-maintenance contains services and timers related to this, and the only one you could optionally enable is btrfs-balance.timer.

It’s not enabled by default for two reasons. It’s not necessary in the general case. In the non-general case we actually kinda need a bug report to track down the problem and get it fixed, whereas running this balance service will prevent the problem from ever being triggered.

2 Likes

The article you mention is from 2019 and seems to be directed towards large systems with RAID filesystems. There have been improvements since then, and laptops are much less robust than the systems considered in the article. Large enterprises assume laptops are going to fail or go missing, so they have OS images for quickly rebuilding a laptop filesystem and large RAID systems to keep copies of user data.

Everyone would like to do less maintenance, but the reality is that ignoring maintenance can have disastrous consequences. With laptops, batteries degrade and dust accumulates on cooling fins.

With larger drives and volumes of data, bitrot becomes more likely. You only find out about bitrot on legacy filesystems when you try to use a damaged file. By that time, the damage may have propagated to backups. Periodic maintenance is integral to the advantages of btrfs over legacy filesystems.

Perhaps, for those borderline cases, automatic recovery via sysfs could be enabled on Fedora?

Since Linux kernel 5.19 there is a sysfs knob to enable automatic block group reclaim. This is essentially the kernel automatically balancing individual block groups as they fall under a certain threshold.

# echo 10 > /sys/fs/btrfs/c3c00bf0-73a6-4aca-91bb-b5e32e76a08c/allocation/data/bg_reclaim_threshold

Good question!

I’m running kernel 6.7.2 and I’m seeing a value of 75. There’s been a plan to enable it by default for a while but I didn’t realize it had been enabled.

1 Like

I don’t have much experience with Btrfs, but I will say that XFS is a fairly safe alternative if you don’t quite trust Btrfs. That’s the file system I tend to use on Linux, though unfortunately very few distros use XFS unless you manually specify it during installation (you have to change the partition type). For BSD and Solaris/illumos I usually go with ZFS, but unfortunately the licensing is largely incompatible with Linux.

Btrfs is supposed to be almost as good as ZFS when they get all the issues ironed out, though, and may eventually surpass it. So definitely keep an eye on it as time goes on.

If you’re on a basic laptop, you can probably just use Ext4, but if you have to change the partition type anyway, I’d give XFS a shot. Ext4 is better for older systems, but if you have a good modern CPU with 8 or more cores, there’s no reason to use Ext4 over XFS.

1 Like

Actually I see a significant reason.

Management of the file system and partitions, specifically when using LVM. Changing the size of an xfs file system when need arises to resize a partition is difficult at best while with ext4 it is relatively simple.

ZFS and XFS have their place but EXT4 is much easier to manage and (I believe) much older in use. I believe the only fedora spin to use anything other than btrfs by default is “server” and resizing a partition there is difficult and cannot be done while the system is active.

BTRFS has been in development for many years and still has quirks that need ironed out before i will commit to using it on my main systems.

I’ve had to recover way more xfs filesystems than ext4 or btrfs - it’s not even close. I’m not saying xfs is bad at all, but it has some significant downsides to it - can’t convert mbr to gpt, no fs-verity, can’t shrink, etc. For most general users, btrfs or ext4 is more practical.

An interesting update regarding this discussion: there are upstream patches aimed at dynamically automating the space.

https://lore.kernel.org/linux-btrfs/cover.1706914865.git.boris@bur.io/

Interesting note:

This can be worked around by:
- enabling automatic reclaim

Neither of these enjoy widespread use, as far as I know, though the
former is used at scale at Meta with good results.

Hello @coco22 ,
To add to the BTRFS is good camp. I began using it when Fedora was thinking of making it default. I have never (until today in fact) ever done any maintenance on the filesystem since the beginning (say F32 for me). I am now running out of room on my /var subvolume (at 90% data) and things are slowing down. I decided to install the btrfs-assistant from the repo and noticed it also include snapper the btrfs snapshot management tool (which is very cool for backing your data up). But also, for my needs (running out of space) I ran the scrub (it took 12 minutes) and am now running balance (which takes considerably longer to complete) on the subvolume in question, to see if I can reclaim some space.
My point being, I never had to do anything until space began being limited, which is not much different for any filesystem out there.
So to answer the question in the title, No you do not need to be the “nanny” of your filesystem if you install with the default BTRFS as Fedora automatically chooses.

1 Like

I’ve been using LVM+XFS for a couple releases just to go back and compare (and tbh I like Red Hat products and just wanted to align with their vision, which may be no reason at all). In all honestly I don’t see a difference and I don’t do anything to “manage” either filesystem. They’ve both been stable, no crashes or anything (I do think there was an XFS bug I happened to miss tbh).

I back up all my stuff and do two upgrades each release (one from GNOME Software to test, then nuke and pave for new defaults if any) though, so maybe my filesystem doesn’t collect enough cruft to have to manage anything.

It’s good to have choices! If it works for you, that’s awesome. Truthfully, I wish we still had the choice to run btrfs in RHEL, but Hyperscale SIG in CentOS Stream or SUSE SLES might be as close as we’re gonna get for a while.

I run btrfs on all of my laptops and workstations. My home server is a mix - it’s ext4 for the mariadb database and btrfs for the regular block data and backups. Much of the stuff at work has traditionally been xfs on Ceph (which is where I’ve had the most trouble with it), but ext4 and btrfs are increasing there lately.

At this point, I wouldn’t hesitate to put the operating system or regular block storage on btrfs for laptops, desktops, and servers alike. Given the choice between ext4 and xfs, I used to not care, but now I strongly prefer ext4 for the better resiliency, overall simplicity, and feature capabilities over xfs. ext4 has largely closed the gap or straight surpassed xfs for things most people would care about in a filesystem. xfs has cost me several nights and weekend hours over the past few years where ext4 and btrfs have not.

Again, this is my opinion based on my own experience. If you like xfs and it works for you, I’m not telling you not to use it. I very much hope you continue to have a good experience with it and that people who use xfs here will contribute in testing and patches to keep it working for those who are passionate about it. I definitely appreciate the testing and passion around btrfs in Fedora.