It’s really unlikely you’re going to break anything inadvertently. You can use it normally and don’t need to babysit it.
If unallocated space gets down to less than 1% remaining, or about 9 GiB on your system, then it might make sense to look at enabling some automatic maintenance. But until then you’re fine.
But if it makes you feel better to just be proactive about space consumption so that you can forget about it, then you can dnf install btrfsmaintenance package and systemctl enable btrfs-balance.timer
The btrfsmaintenance upstream is the kernel’s btrfs maintainer (kdave).
Yeah, btrfs dynamically allocates block groups. This allows it to create the right amount of metadata and data block groups for the actual workload on that system.
But btrfs also favors using the unused space in existing block groups. So it’s normal to see the percent usage of block groups to be high.
If usage is high, and also little to no unallocated space, that becomes a concern. But usually this doesn’t happen until the file system is legit getting full, > 90%.
Even more details are found with btrfs inspect-internal list-chunks / [1]
[1] Equivalent to btrfs insp list / - I like pointing out that users can arbitrarily shorten btrfs commands so long as it’s unabiguous.
Well, not to enhance your worry, but any number of things can go wrong. Your file system isn’t going to run out of space any time soon unless you have a significant space consuming workload you’d like to tell us about.
My suggestion is a solid backup plan to make all worries more or less go away. Yes, a clean install and restore is tedious, but not so worrisome.
I’m offhand not aware of any case of out of space leading to data loss. We’re always able to, worst case, mount the file system read-only and get important data out using normal means like rsync or borg or whatever your favorite utility is.
Perhaps counter intuitively we see more issues with out of space as a result of excessive metadata rebalancing. I suggest most users don’t need to balance. I never balance. But if you really want to make sure you don’t have to worry, btrfs-balance.timer
Pretty soon periodic and dynamic reclaim will be enabled for data block groups in the kernel. Everyone will get that. And that will further reduce the likelihood of out of space cases.
Is anyone aware of a way someone could be notified when their filesystem is getting close to being full? Would be nice to get a warning while things could still be cleaned up instead of letting it fill up.
I’ve only heard of this with Btrfs so far. Prior I heard of concerns with SSDs being full because of trim or something, but that wasn’t filesystem-specific.
Why doesn’t Btrfs handle that better? Disk space usage should be based on the disk size itself not being able to technically store more on physical medium (metal platters can only hold so many 0s and 1s ), vs software-based algorithms doing guess-work on percentages.
I haven’t heard of that on ext4 or XFS and currently believe them to be better defaults.
The delay from fallocate to the pop-up warning was a few seconds. This is on Fedora Workstation 43, but I’m pretty sure this feature has been around for a while.
OK so remove that and try 170G. No warning. This is 98% full. This could use some improvement. I don’t know the correct percentage to warn on, but it seems like 2% is cutting it a bit close.
In any case, 334 MiB was enough unused space for me to remove the file.
Hmm
$ gsettings get org.gnome.settings-daemon.plugins.housekeeping free-percent-notify 0.050000000000000003
$ gsettings get org.gnome.settings-daemon.plugins.housekeeping free-percent-notify-again 0.01
These values seem reasonable, I guess I’ll need to poke at it some more.
ext4 has a 5% reserve that only root processes are allowed to dip into. I’m not sure if xfs has any sort of reserve.
Btrfs, the amount varies, but not even root processes are allowed to use this reserve. It’s really strictly for ensuring we can delete some files and back things out, without getting a file system that’s stuck full.
Why is that possible? Btrfs is COW, and has no fixed locations for its metadata. That means it will consume free space when deleting files, because it needs to write the metadata changes into unused space. Therefore deleting files increases space consumption initially. Only once the updated metadata is on stable media, is it possible to free the space from the deleted files. And it turns out this can bring difficulties.
), vs software-based algorithms doing guess-work on percentages.