btrfs-progs VS systemd-swap

Not an error I've seen before or that makes much sense to me at first glance, might want to take this to https://github.com/kdave/btrfs-progs/issues or the mailing list?

You can test it by allocating the space to see if it can use it all: e.g. fallocate -l 3.8t /mnt/elfstone2/butts should succeed. If it does, then it's probably fine even if the balance didn't do what it should have. If not and you run out of space with some unallocated space left on only one device, not so much. If its the same bug I saw that means if your fs was created pre kernel 5.19, it will not allocate correctly on >5.19 until the array is rebuilt under the newer kernel.

Mount options should be documented either at https://btrfs.readthedocs.io/en/latest/Administration.html or at the manual page section 5 (man 5 btrfs). Autodefrag is in section https://btrfs.readthedocs.io/en/latest/Administration.html#btrfs-specific-mount-options . In case you find more information missing, unclear, lacking cross-references please open an issue at https://github.com/kdave/btrfs-progs/issues .

thanks. I filled a feature request... https://github.com/kdave/btrfs-progs/issues/610

Resume sort of doesn't work, when you resumed it will have started a fresh balance with a high usage value (check your syslog to confirm).

That's the hint. It's an unfixed bug with the accounting when scrub is paused and resumed, the relevant issue is I think https://github.com/kdave/btrfs-progs/issues/227 .

[1] - https://github.com/kdave/btrfs-progs/issues/277

Hoping for a filesystem clone option at some point.

As a bonus, the systemd-zram-service's scripts will create zRAM devices based on the number of your CPU cores. This is problematic as it's a deprecated practice, and can also cause an issue on some multicore CPUs. Basically, we already have "multi stream functionality" since kernel 3.15. And since kernel 4.7, regardless of the value passed to [max_comp_streams], zRAM will always allocate multiple compression streams - one per online CPU - thus allowing several concurrent compression operations.

Historically, Linux has created an additional (fixed-size) swap partition or file. In case you mention you get OOM. But for some time there is a great project systemd-swap creating hybrid swap space. You can even find it in the official Arch Linux Community repo.

There is also systemd/zram-generator that allows you to create and manage swap devices more easily. And Nefelim4ag/systemd-swap (abandoned?) that automatically creates swap files and resizes them based on RAM usage.

SwapFC - https://github.com/Nefelim4ag/systemd-swap

That sound like what systemd-swap does. Apparently, hibernation is not quite working yet, though.

https://github.com/Nefelim4ag/systemd-swap

Disclaimer: I couldn't find anything relating to SwapFC other than from the README of systemd-swap. What I've written above is just based on the one-line description of SwapFC, as well as prior knowledge of zswap and zram (obtained from the Linux Kernel docs).