Re: booting btrfs

[Chris Murphy]

On Oct 13, 2013, at 11:28 PM, Andrey Borzenkov <address@hidden> wrote:

> В Sun, 13 Oct 2013 17:58:41 -0600
> Chris Murphy <address@hidden> пишет:
> 
>> 
>> On Oct 13, 2013, at 5:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
>> <address@hidden> wrote:
>> 
>>> On 13.10.2013 22:59, Chris Murphy wrote:
>>>> 
>>>> How does one create a subvolume without a name? All subvolumes have had 
>>>> ID's since at least 2008, and it's been possible to mount by name or ID 
>>>> for quite a few years at least as well.
>>>> 
>>> Then this illusion was created by the /proc/mountinfo listing mounted
>>> subdirectory as "/" when mounted by id (or something like that).
>> 
>> The top level subvolume (id 5) is likely reported as "/" just like is the 
>> case when mounting any file system.
>> 
>> It's possible that changing the default subvolume causes this same behavior 
>> rather than mount reporting the full path. I haven't tested this.
>> 
> 
> No, it is inconsistent behavior for named subvolume and subvolume ids
> mounts.
> 
> For named subvolume btrfs internally mounts top level directory
> (actually using subvolid=0 for this internal mount) and then performs
> equivalent of bind mount on subvolume. For subvolid it actually
> sets root of filesystem to subvolume during mount. As mountinfo
> displays path relative to filesystem root, it is always "/" if subvolid
> was used. I do not know if there are practical differences between the
> two.

I'm finding partial corroboration with this. Mounting subvolid= does not show 
either subvolume id or name, which seems like a problem.

At the moment, I'm unable to confirm/deny that mountinfo correctly shows full 
path because when I change the default subvolume, I'm dropped to a grub rescue 
prompt on the next boot. This isn't expected because set reveals:

prefix=(hd0,msdos1)/boot/grub2
root=jd0,msdos1

In fact, /boot is a subvolume under top level 5. So if GRUB is using full 
paths, which it seems to be, it should be able to still resolve this even 
though the default subvolume is not the top level 5 subvolume. Yet it's not 
working. So it seems that GRUB is using relative pathnames to the default 
subvolume. That's a problem also because it effectively means btrfs subvolume 
set-default can't be used without breaking bootability.


> 
> Why full paths are cumbersome? The
> 
> mount -o subvol=path/to/boot /dev/sdX /mnt
> vi /mnt/grub/boot.cfg
> 
> is 100% equivalent to
> 
> mount -o subvolid=0 /dev/sdX /mnt
> vi /mnt/path/to/boot/grub/boot.cfg

It's not 100% equivalent in behavior. For one, paths can become quite long 
depending on the snapshotting strategy and complexity of the hierarchy. If that 
hierarchy ever changes, now the mount option must change and the grub.cfg must 
change or the system is unbootable. That's not the case with ids; the system 
remains bootable without having to modify fstab or grub.cfg.


> 
> And GRUB is concerned only with value of $prefix. So as long as
> grub-install can resolve path name of /boot/grub to full path from
> btrfs root including subvolumes it is OK.

I'm uncertain about this, because upon changing the default subvolume, I can't 
boot. Hence at least core.img appears to treat what looks like a full path, as 
relative to the default subvolume, whereas full paths should always be treated 
relative to top level 5 subvolume.

> And to use subvolume ID you
> will need to detect that path is on subvolume anyway.

I don't know what this means. The file system clearly can resolve the location 
of a subvolume independent of path.

> 
>> Today, maybe it's not the best scenario to have two or three OS's installed 
>> on one btrfs volume, in separate subvolumes, each with hundreds of 
>> snapshots. But it's designed to enable such a workflow once it's stable. I 
>> think using full paths (always relative to the top level subvolume which 
>> never changes even if the default subvolume is changed) is fine in the near 
>> term. And it may be some workflows simply prefer the (human user) 
>> transparency that comes with full paths. But from my perspective, a fixed 
>> number means I can completely reorganize a hierarchy with no other changes.
>> 
> 
> Could you please provide example of what you mean here?

If I use subvolid's everywhere, it means I could grab Fedora's default 
hierarchy: boot root home, which are subvolumes, and move them into a either a 
folder or subvolume called "Fedora 20" and upon reboot everything still works. 
Right now, that's not the case. If I move these things, or rename them, boot 
breaks.

It's sortof like using volume labels or partition names to quality paths. 
There's a reason why UUID is preferred to labels, because if the user depends 
on labels, then relabels a volume, they can't boot. So there's a better way to 
do this that preserves the user's ability to name user domain things like 
volume labels, while not breaking system domain things like an immutable way of 
booting the system.

It's about making bootability more robust.



>>> The rename may very well be
>>> intentional in order to make other OS and/or version to boot.
>> 
>> Yes, and I'm not suggesting the end to supporting either full path, or 
>> relative path referencing of subvolumes. Just that it's also possible to use 
>> subvolid.
>> 
> 
> What about grub-mkconfig? It does not pass explicit subvolume if it is
> not present in mountinfo, which means a) if someone changes default
> subvolume it will end up mounting wrong root and b) it breaks if mount
> by subvolid is used.

Clearly there are some things returned by mountinfo that need fixing and 
enhancement. The same can be said about the mount command. And tools like 
gnome-disk-utility need some things about