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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
