[systemd-devel] /var/lib/machines be a mounted subvolume rather than an actual subvolume?

[Chris Murphy]

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