Re: booting btrfs

[Andrey Borzenkov <arvidjaar@gmail.com>]

В Sun, 13 Oct 2013 17:58:41 -0600
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Oct 13, 2013, at 5:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> 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.

> > 
> >> and some behaviors like entirely unique file systems volumes.
> > I feel like subvolumes are glorified folders and would have prefered
> > directories becoming more powerful rather than having a completely new
> > concept.
> 
> That's not possible. It had to be this way to support snapshotting. A snapshot is a subvolume. The subvolume only appears as a directory, in reality the directory links to the subvolume which are a completely separate btree and analogous to a whole separate file system. And since its a separate file system, the inode numbers start over. Conversely a directory is just an item like a file in the tree, it's not a tree in its own right, which a subvolume is.
> 
> > On both ZFS and btrfs as far as GRUB is concerned are directories with
> > just slightly different structure.
> 
> Understood, but I think this is less ideal. It offers less leverage and usage of  the file system as a boot, even as rootfs, file system.
> 
> > Why would numbers be preferable to names?
> 
> Without the use of subvolid= we  either have to always use full paths for subvolumes (instead of relative), or we can't use btrfs set-default to change the default subvolume. If the paths to subvolumes are relative to the default subvolume, then changing the default subvolume breaks booting. And full paths could become rather cumbersome, since the hierarchy is effectively unlimited.
> 

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

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. And to use subvolume ID you
will need to detect that path is on subvolume anyway.

> 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?

> > 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.