[systemd-devel] systemd-tmpfiles subvolume handling vs. changing default btrfs root

[Ignaz Forster]

Am 27.06.2018 um 13:39 schrieb 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?

With "recursive snapshots" I assume you mean putting the snapshot below 
the original root file system?

If so that's not how the btrfs subvolumes are organized in this case: 
The "@" subvolume itself is almost empty and only contains further 
subvolumes.
During *SUSE setup everything will be installed to 
"@/.snapshots/1/snapshot" instead, and this subvolume will be set as the 
default btrfs subvolume (which would be equivalent to using the mount 
options 'subvol=@/.snapshots/1/snapshot' for '/').

After installation a tool called Snapper (default on *SUSE, but also 
available on several other distributions) will take care of snapshot 
management (e.g. by creating a new snapshot on system changes).
Now if a user wants to do a rollback, the default btrfs subvolume will 
just be set to that specific snapshot and makes that one the new root 
file system.

This design is intentional by relying on btrfs' feature to change the 
default subvolume, and thus imho works a designed.
-- 
Ignaz Forster <iforster at suse.com>
Research Engineer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-281;  https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)