According to the archwiki article on a swapfile on btrfs: https://wiki.archlinux.org/title/Btrfs#Swap_file
Tip: Consider creating the subvolume directly below the top-level subvolume, e.g. @swap. Then, make sure the subvolume is mounted to /swap (or any other accessible location).
But… why? I’ve been researching for a bit now, and I still don’t understand the benefit of a subvolume directly below the top level subvolume, as opposed to a nested subvolume.
At first I thought this might be because nested subvolumes are included in snapshots, but that doesn’t seem to be the case, according to a reddit post… but I can’t find anything about this on the arch wiki, gentoo wiki, or the btrfs readthedocs page.
Any ideas? I feel like the tip wouldn’t just be there just because.
I personally prefer top level subvolumes (@, @home, @var-log, @var-cache), because it makes it easier to know which system folders are subvolumes and back them up accordingly. They are then mounted at their respective location under
/.E.g… I do snapshots looking at the btrfs filesystem and its top level subvolumes. I’m not doing snapshots going from the mounted root filesystem. I.e. I’d do a snapshot of
@home, not a snapshot of/home.If you want to use backup/snapshot automation tooling, I’d recommend looking at how they expect the subvolumes to be set up. E.g. snapper and timeshift expect a specific layout (which can stil be done manually after OS installation, but why bother).
I think it is so that the subvolume can be mounted with different options. You can of course have a mixed layout which might be more convenient, so that say root and home subvolumes mount with the same options, but swap mounts with different options. And the top level never gets mounted at all.
toplevel (not mounted) +-- @ (subvolume mounted on /) +-- home (subvolume, looks like a folder, same mount options as @) +-- usr (folder, gets snapshotted by @) +-- ... +-- @swap (subvolume with different options, mounted on /swap)I set mine up with a purely flat layout so I haven’t verified this is true, but it sounds reasonable.
Here’s the documentation I was looking at:
not to do the “read the manual” thing, but the manual is linked from archwiki and has at least 5 bullet points of limitations and all the whys to go with them
Yeah, I read that manual but it didn’t answer my question.
The big problem is that the arch wiki describes a setup with nested subvolumes first (in a subvolume below @ or whatever your root subvolume is), but then suggests in a tip to use a subvolume directly below the top level subvolume. The limitations mentioned in that manual don’t seem to apply to either setup, as they would prevent swap from working, which is not the case. I have tested both setups and they work fine — or so it seems. I’m worried there is some hidden gotcha I’m missing.
in addition to that, some of those limitations simply don’t apply to my setup, as I only have a single device.
They share the same partition, but they’re treated like independent filesystems. They can have different mount options, so on one you can enable compression but not another some you may want to disable Copy-on-Write, etc. That’s also useful so you can rollback a system update without also rolling back your data or vice-versa. You can also store multiple distros each in a subvolume and boot different ones all while sharing the same partition and not wasting space. If you have multiple users it’s worth having a subvolume each so each user can independently rollback their home directory. Maybe you want your projects on a subvolume so you can snapshot and btrfs-send it frequently.
I don’t use btrfs but on ZFS I have tons of datasets: steam library gets large recordsize and light compression, backups are heavily compressed and encrypted, VMs have a dataset tweaked for disk images, my music and movies also have a larger recordsize but no compression. I have one that’s case insensitive that’s shared with Windows machines and Wine stuff. I cap the size of caches and logs.
It’s very versatile.
Not a specialist, but I suppose it has to do with having different configurations for different top level folder. In Unix-like systems, every top level folder have a different purpose, and what works for the root may not for /tmp, /swap, etc.
In those example, no need to snapshot /tmp, as it is a forder whose file are bound to be deleted, and for which being able to restore has no use.
/swap is pretty similar, and is often formated with a dedicated filesystem.
/usr often only change during the package manager transactions, so snapshots are often tied to that, while /home may be set to keep daily snapshots.
