Am 27.06.2018 um 16:34 schrieb Lennart Poettering:
On Mi, 27.06.18 15:50, Ignaz Forster ([email protected]) 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 <[email protected]>
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)
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
