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

[Lennart Poettering]

On Thu, 16.07.15 12:40, Chris Murphy (lists at colorremedies.com) wrote:

> 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?

so that you can apply quota not only on the individual containers, but
on them all together, as well as query disk usage of the all summed up.

> 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?

No. it can be anything. systemd will create it as subvol if it is
missing, and you will get more features if it is a subvolume (like the
quota/disk usage stuff menionted above) but it degrades gracefully if
it is just a normal dir.

Lennart

-- 
Lennart Poettering, Red Hat