[systemd-devel] systemd-tmpfiles subvolume handling vs. changing default btrfs root
Ignaz Forster
iforster at suse.de
Wed Jun 27 13:50:26 UTC 2018
Am 27.06.2018 um 15:37 schrieb Lennart Poettering:
> On Mi, 27.06.18 15:09, Ignaz Forster (iforster at suse.de) wrote:
>
>> Am 27.06.2018 um 13:39 schrieb Lennart Poettering:
>>> On Mi, 27.06.18 13:02, Ignaz Forster (iforster at suse.de) 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".
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.
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)
More information about the systemd-devel
mailing list