systemd-tmpfiles subvolume handling vs. changing default btrfs root

[iforster@xxxxxxx (Ignaz Forster)]

Am 27.06.2018 um 16:34 schrieb Lennart Poettering:
> On Mi, 27.06.18 15:50, Ignaz Forster (iforster at suse.de) wrote:
> 
>>> 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.
> 
> I still don't grok this. What's the precise problem then?

The problem is that the subvolume layout may not always be the way 
systemd-tmpfiles expects it to be. This is caused by different possible 
ways of handling rollbacks to a previous snapshot.

I'm aware of three common patterns on how to restore a previous snapshot 
of the system (i.e. the root file system):
1) Use 'mv' to move the backup to the original location
2) Delete the root file system snapshot and recreate it using the backup 
snapshot as a parent
3) Set the default btrfs subvolume to the backup snapshot subvolume (or 
a copy of it)

I'm talking about case *3* here. Whenever one wants to roll back to a 
certain snapshot one would just call e.g.
	btrfs subvolume set-default /.snapshots/123/snapshot/
and reboot.

In contrast to case 1 and 2 there is no dedicated static "/" subvolume 
(which also implies this is not a "Nested", but a "Flat" or "Mixed" 
layout as outlined on 
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout), but the 
default btrfs subvolume will always point to the snapshot of the last 
rollback. (On openSUSE this mechanism is also used for read-only systems 
where each update will switch to a new snapshot.)


I'd sum this up as: subvolumes for system directories should never be 
created as childs of a snapshot as snapshots are a variable thing.

> The assumption systemd-tmpfiles makes is always that the subvolumes
> it implicitly creates for you if they are missing are associated
> with the subvolume they are created below, and that this means they
> are snapshotted, removed and otheerwise managed along with them.

Keeping this logic more or less assumes that snapshots will always be 
used as static backups and pattern 3 from above must not be used.

However not only *SUSE or snapper are using this pattern, but several 
websites also suggest this workflow - that's why I'm interested in 
upstream support.

> systemd will never create disassociated subvolumes for you.

That's the problem - it will create subvolumes which will just disappear 
from the system when switching to the next snapshot.

> If you
> want that use some other tools, but tmpfiles is not really supposed to
> do complex stuff like that.

The added complexity is the reason why I brought this to the list. 
However I'd (obviously) still prefer compatibility with a larger array 
of btrfs layouts by default.

Finding the subvolume and making sure it's mounted on the next boot 
(e.g. by adding an fstab entry or a mount unit) would be the most 
complex part about this.

> But quite frankly I don't grok the problem at hand, i.e. what you are
> trying to do, even.

Was this explanation any better?

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)