systemd-tmpfiles subvolume handling vs. changing default btrfs root

[iforster@xxxxxxx (Ignaz Forster)]

Am 27.06.2018 um 15:37 schrieb Lennart Poettering:
> On Mi, 27.06.18 15:09, Ignaz Forster (iforster at suse.de) wrote:
> 
>> 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?
> 
> By recursive snaphots I really mean recursive snapshots, i.e. if you
> have a subvolume called `/foobar` and there's a subvolume below it
> called `/foobar/var`, and you'd make a snapshot of `/foobar` and call
> it `/foobar2`, then this would implicitly also have the effect of
> snapshotting `/foobar/var` and calling it `/foobar2/var`, so that each
> snapshot is always "complete".

Ah, I see - no, that's not the problem here.
The subvolumes are there because we do *not* want to snapshot them.

It's guess it's best to just ignore the second bullet point - it's a 
follow up problem, but it isn't really important for the main point: 
Attaching a new subvolume to a snapshot.

Ignaz
-- 
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)