Resurrection of related thread "systemd and nested Btrfs subvolumes" from March: http://lists.freedesktop.org/archives/systemd-devel/2015-March/029666.html
The question: I understand the argument for subvolumes for containers below /var/lib/machines. I don't understand what feature(s) of Btrfs subvolumes will be leveraged for /var/lib/machines itself, and why it isn't just a regular directory that then contains whatever subvolumes are needed? The problem: On openSUSE, it uses subvolumes at the top level of the file system (in subvolid 5) to make certain things exempt from snapshotting and rollback: like logs, mail, bootloader, and system settings. See the fstab in the above URL to see the listing. The fstab containing that long list of subvolumes to mount ensures that those identical subvolumes are always used no matter what subvol/snapshot the user rollsback to. But there isn't an fstab entry for /var/lib/machines. So a.) it won't get snapshot by snapper and b.) if a rollback is done, the backing subvolume containing all the nspawn container subvolumes won't be mounted, it will be empty. The solution: The implied fix for this is to create the subvolume <FS_TREE>/var/lib/machines at installation time, and add it to fstab to always mount at /var/lib/machines (a directory found in all snapshots of /). https://features.opensuse.org/319287 As a consequence, it means if there's a rollback, it's not possible to delete /var/lib/machines - its contents can be deleted but a mounted subvolume can't be. Hence the question, rephrased, does systemd expect /var/lib/machines to be an actual subvolume rather than a mountpoint backed by a mounted subvolume? -- Chris Murphy _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
