Re: booting btrfs

[Chris Murphy]

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.

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

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.

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


Chris Murphy