systemd-tmpfiles subvolume handling vs. changing default btrfs root

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Mi, 27.06.18 13:02, Ignaz Forster (iforster at suse.de) wrote:

> Hello,
> 
> when using systemd-tmpfiles' feature to create subvolumes it will always
> create the new subvolume as a child of the subvolume of the given path. This
> however may not always be the expected parent, especially when using btrfs
> snapshots to switch between various system states.
> 
> Example layout:
> ===============
> 
> Let's assume the following subvolume layout (a simplified openSUSE layout):
> 
> ID	parent	top level	path	
> --	------	---------	----
> 257	5	5		<FS_TREE>/@
> 258	257	257		<FS_TREE>/@/var
> 259	257	257		<FS_TREE>/@/.snapshots/1/snapshot
> 260	257	257		<FS_TREE>/@/.snapshots/2/snapshot
> 261	257	257		<FS_TREE>/@/.snapshots/3/snapshot
> 
> A corresponding /etc/fstab could look like this:
> 
> /dev/sdx	/	btrfs	defaults	0	0
> /dev/sdx	/var	btrfs	subvol=@/var	0	0
> 
> with the default btrfs subvolume set to "261".
> The third snapshot would thus be the root file system, with /var mounted on
> top of it.
> 
> 
> The problem:
> ============
> 
> Creating "/var/test" would create a new entry like
> 262	258	258		@/var/test
> as expected.
> However creating "/opt" would create an entry similar to the following:
> 263	261	261		@/.snapshots/3/snapshot/opt
> 
> This is not good, as two things will happen now:
> * When changing the snapshot (e.g. by reverting back to an old snapshot or
> creating a new one) /opt won't be visible any more (without manually
> mounting it), as it is not nested into the existing structure any more
> * The third snapshot cannot be deleted without removing the
> subvolume first

I am not sure I follow here fully. but isn't this just a shortcoming because
you are not doing recursive snapshots? why not just fix that?

Lennart

-- 
Lennart Poettering, Red Hat