R: Re: Question about btrfs as root filesystem

Goffredo Baroncelli
Fri, 08 Nov 2013 12:55:06 -0000

>On Nov 7, 2013, at 4:45 PM, Michael Göhler <visit@myjm.de> wrote:
>>  The boot subvolume is then set with ''btrfs subvolume
set-default'' and
mounted without subvol/subvolid option by Arch''s default mount
handler.
>
>I''m unconvinced it''s a good idea for it to be used behind
the scenes
> for the described purpose. Consider the following:
>
>1. btrfs subvolume set-default uses a user space tool and in
> my view it''s primarily a user domain behavior modifier for the
mount
command.
>
>2. It makes the actual mounted subvolume obscured, cat /proc/self/mountinfo
> doesn''t show what subvolume is mounted unless subvol= is
explicitly used in
/etc/fstab.
>
>3. Grub2 (and I''m pretty sure grubby) do not use the set-default.
The GRUB
> intent for the prefix to search an absolute path, not one relative to the
> default subvolume. There''s a bug that should very recently (week)
be fixed,
> where GRUB fails to find prefix if set-default is changed. This maybe
isn''t
> affecting the particular layout you describe where only rootfs is on btrfs,
> rather than /boot being on its own subvolume.
>

Instead of using set-default, I am used to rename the subvolume.
I.E. I assume that the root filesystem is a subvolume always called
"__active".
When I want to rollback, I rename "__active" in "__broken"
(or
remove it), then I rename (or re-snapshot) "snapshot-yyyymmdd"
in "__active".

>> That way, we ensure the best compatibility and lowest maintenance,
> as we don''t overwrite default init functions.
>
>I''m sympathetic to the alternative problem, which is that you need
to
> alter grub.cfg to use the proper rootflags=subvol= to explicitly use the
> proper snapshot, and also it would mean altering the /etc/fstab within
> that snapshot.

With rename you can address both the issues

>>
>> Now, if we snapshots the root subvolume, the child subvolumes are
>> not snapshoted with it. There is no back reference which would
>> allow Btrfs to auto-mount the original child subvolumes when we
>> mount the snapshot as new root filesystem. Of cause we could
>> snapshot the childs separately into their desired directories. But
>> this would not help, because our hook snapshots the snapshot again,
>> to keep it''s original untouched while rolling back.
>> And we don''t have fstab to find out the correct mount points
at this early
boot stage.
>
>The fact of the matter is, we don''t have the necessary metadata
support in
> btrfs to understand the relationships between snapshots/subvolumes.
> There is a need for this, not least of which is the use case
you''re
> describing. This has come up with Fedora also for their offline
> updates rollback they want to eventually do. And it''s also an
issue
> with distribution installers which see these snapshots as wholly
> unique instances of existing installations, rather than as related
snapshots.
>
>
>>
>> Atm. all scenarios results in /usr/bin/init not found.
>>
>> So here comes my question:
>> Wouldn''t it be helpful to add a --recursive option to
''btrfs subvolume
>> snapshot'' to snapshot child subvolumes together with their
parent?
>> Or maybe it is possible to add some functionality to reference the
>> child subvolumes on the snapshots fs-tree to allow auto-mounting?
>
> Well and it raises the problem of nested subvolumes making the parent
> subvolume undeletable. So I''d question the significant benefit of
> making nested subvolume in particular /var. It''s complicating
> how the OS is to be put back together again.

IIRC the problem of removing a subvolume with a child subvolume,
already exists. IMHO the "btrfs sub snapshot"  --recursive option
could have some valid uses cases. Of course we should add the
"btrfs sub delete" --recursive option also.

BTW I agree with Chris that partition the filesystem in too much
subvolume is a mess from a managemente POV. May be
adding an option to "ls" to highlight the subvolumes could
alleviate the problem ?

G.Baroncelli
>
>
>Chris Murphy--
>To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--