[Solved] Benefit of a subvolume below the top level btrfs subvolume?

2024-06-13 06:02 UTC

According to the archwiki article on a swapfile on btrfs: 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 put my solution as a comment so people who sort by new comments see the update.

Replies (1)

@moonpiedumplings@programming.dev 2026-07-21 23:03

Two years later, and I have an answer, after reading this: archive.kernel.org/oldwiki/…/SysadminGuide.html#S… which was linked from the Arch Wiki, but it is the old wiki, which is obsolete and no longer updated. Basically, in a nested subvolume layout, the nested subvolumes inherit mounting options of their parent subvolume. This might be changeable, but it’s the default. On the other hand, separate subvolumes have their own mount options. Although not really important for a swap file, since the file itself can have copy on write features removed, you might want this if you want a subvolume containing folders of data where you want copy on write disabled for performance purposes. This matters for things like postgres, which has it’s own alternatives to journaling/CoW: Because WAL restores database file contents after a crash, journaled file systems are not necessary for reliable storage of the data files or WAL files. In fact, journaling overhead can reduce performance, especially if journaling causes file system data to be flushed to disk. Fortunately, data flushing during journaling can often be disabled with a file system mount option, e.g., data=writeback on a Linux ext3 file system. Journaled file systems do improve boot speed after a crash. From here: www.postgresql.org/docs/18/wal-intro.html And then the other benefit of a top level subvolume is management. You can mount it anywhere you want. You can mount it independently of other btrfs subvolumes, meaning you could share a swap file between two installed distros to save space, although this breaks hibernation, so you probably wouldn’t want that. It’s just that top level subvolumes give you flexibility nested subvolumes don’t.

Open ##3998426