I think you do? Usually the numbers for `musage` are smaller I think.
There is some old advice that you should only balance data and never balance metadata, i.e. `btrfs balance start -dusage=70 $mountpoint`. This is because 1Gb blocks are assigned to either data or metadata, and it's possible for excessive balances to result in a situation where the metadata gets only a single 1Gb block and the rest of storage is assigned to data. Then the single metadata 1Gb block gets filled, and when new metadata is needed --- such as to rebalance the large number of data blocks so they take up fewer 1Gb blocks and more blocks can be assigned to metadata --- the filesystem is unable to continue operating due to the lack of metadata space and you are stuck in a condition where you cannot delete data, delete snapshots, and rebalance data.
This is old advice since the new "GlobalReserve" (not so new I think, it was added way back in 4.x? 3.x?) should provide space for temporary metadata operations in such a case. Personally I'd rather just let metadata be "loose" and unbalanced to avoid the situation altogether; metadata is fairly tiny so it taking up more than one 1Gb block usually means it has two 1Gb blocks, maybe three at a stretch if you've been doing a lot of file creation and deletion events.
Another piece of old advice is to regularly balance. For example, have a daily `btrfs balance start -dusage=50 -dlimit=2 $mountpoint` --- the `dlimit` makes it so that balancing stops when two 1Gb blocks of data have been merged into some other half-filled 1Gb blocks of data. If you have never balanced your BTRFS system, you might want to wait for some low-utilization time period, do a full `btrfs balance start -dusage=90 $mountpoint` without a `dlimit`, then schedule a daily balance of `-dusage=50 -dlimit=2` afterwards. On the other hand, if you're using SSDs, be aware that balancing leads to writing, which lowers your drive's longevity (but the point of `dlimit` is to prevent excessive amounts of daily work, and if you're regularly writing to your disk (almost) everyday anyway, a small `dusage` and `dlimit` would be within the noise of your daily-work-activity writes).
You also want to do regular `btrfs scrub start $mountpoint`. Once a week for consumer-quality drives, once a month for enterprise-quality drives, if you're not sure which one you have, go weekly. This is advice typical from ZFS but should still apply to BTRFS.
On SSD (or other storage with TRIM commands) you might want to do scheduled trim regularly once a week or once every two weeks, in order to take allocation pressure off the SSD and let it get better wear-levelling. This is generally done via `fstrim` without any BTRFS-specific commands. Old advice is to avoid the `discard` mount option (in some cases it can trim so often that the SSD lifetime is significantly reduced) but that's supposed to be fixed so maybe with a recent version you can mount `-o discard`, maybe. Personally I'd use explicit scheduled trim still. Do try to schedule this at low-activity times, though; unless you've got SATA 3.1 (hard to check, most drives/controllers just say "SATA 3" or "SATA III" which may or may not mean including SATA 3.1 support), or SAS, or real SCSI, trim commands are slow.
Finally you might also want to do explicit defragmentation (which is a separate issue from balancing --- balancing ensures you don't have lots of half-used blocks, defragging means files try to have as much of their data in the same 1Gb block) periodically, like once a week or two weeks.
See also
https://github.com/kdave/btrfsmaintenancefor a package that does btrfs maintenance for you, including balance, scrubbing, trimming, and defragging, and schedules those in "recommended" times as well. I think it might also have auto-snapshotting, though that is a bit more fraught as snapshots are fairly heavyweight on BTRFS. Do note that it's crontab/SystemD-based though, so needs a good amount of glue code if you want to use it in Guix. It's available on Debian as `btrfsmaintenance` package. It's also got a lot of settings, so you'd be up for a fairly comprehensive configuration system to adapt it for Guix.
Going back on topic... It looks like the test assumes "free" should equal "available", but that is something that is likely not to work on ***all*** copy-on-write filesystems --- including ZFS and bcachefs, not just BTRFS. In particular, most copy-on-write filesystems (BTRFS, ZFS, and bcachefs) support transparent compression, meaning "available" is often an estimated multiple of "free". Probably the test should either explicitly use a specific filesystem (maybe `tmpfs` would work? Or create a 1Gb "dd if=/dev/zero` file in `/tmp` and bind-mount `ext4` onto it) that is simple enough that "free" == "available" most of the time, or it should just remove that particular test.
Thanks
raid5atemyhomework
