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

[Lennart Poettering]

On Mi, 27.06.18 23:25, Ignaz Forster (iforster at suse.de) wrote:

> 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 children of a snapshot as snapshots are a variable thing.

tmpfiles won't create any subvolumes for you — except if they are
missing. tmpfiles can't guess the complex mappings you applied to your
tree, it can't know that you don't want to allow recursive snapshots,
but place them all in the same dir and bind mount them. Also, if I
understand correctly the way suse sets this up always *requires*
additions to fstab for any subvol created, which is clearly out of
focus for tmpfiles.

Also, tmpfiles won't actually create any subvols below /usr (unless a
user dropped something in to do that on its own), it will only do so
in the root dir for precisely /var, /tmp, /home and /srv. All others
are created below /var. Which means you rule of "don't create subvols
below system directories" isn't actually touched, because the
read-only OS is monopolized in /usr anyway... Or maybe I am still not
getting what you are trying to say?

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

I don't see that at all. I mean, this all depends how you want to
associate /var with /. my assumption is that they belong together, but
i figure that's not what you have in mind? you want to keep using the
same /var even though you switch back and forth to different /?

i am not sure if follow fully, but i think the model should be the
other way round: keep the root file system in one subvolume, and keep
/usr completely separate from that, and only combine the two through
bind mounts when you want to go for one specific version. In that
mode, all subvolumes systemd generates would be children of the root
subvolume, as they should be, but /usr would be separate.

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

Well, no, if snapshots are done recursively they wouldn't, they would
be switched at the same time.

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

Not really still, what I don't grok what precisely a "system snapshot"
in suse terms is actually supposed to entail. Is it supposed to
contain only the vendor RPMs, i.e. only /usr? or everything except
/home, /srv, /var, /tmp? Or the inverse of that?

Lennart

-- 
Lennart Poettering, Red Hat