On Mi, 27.06.18 15:09, Ignaz Forster ([email protected]) wrote:

> Am 27.06.2018 um 13:39 schrieb Lennart Poettering:
> > On Mi, 27.06.18 13:02, Ignaz Forster ([email protected]) 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".

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to