Re: booting btrfs

[Chris Murphy]

On Oct 13, 2013, at 1:47 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
<address@hidden> wrote:

> On 13.10.2013 20:04, Chris Murphy wrote:
>> On Sep 26, 2013, at 4:15 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
>> <address@hidden> wrote:
>> 
>>> On 26.09.2013 22:51, Chris Murphy wrote:
>>>> 
>>>> Open question is if on BIOS hardware, if a 1MB BIOSBoot is preferred over 
>>>> the 64KB Btrfs bootloader pad?


What about this question?


>> 2nd question is whether additional things are needed for /boot on btrfs. 
>> Using qemu/kvm and vbox I've tested maybe 6 virtual disks using btrfs 
>> single, raid0, raid1, and raid10 configurations, and consistently GRUB can 
>> boot /boot as a subvolume. I don't know how resilient this is as the file 
>> system is used and chunks end up on different devices or if this is 
>> sufficiently abstracted that it doesn't matter and just works; including if 
>> devices are removed and added.
>> 
> One thing that we would really need is some stability on the level of
> concepts. It happened several times in the past and when it happened
> again with mounting by volume id, the stance is that as long as concepts
> change so regularly and we get no notification or consultation from
> devs, we should keep code as-is and handle, that is handling sane cases
> and skip the others, like subvolumes without a name.

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.

What is new since kernel v3.2, almost 2 years ago, is the ability to mount 
subvolumes by full path, relative to top level subvolume rather than the 
default subvolume. This didn't change a basic concept, it just made an existing 
one a lot more flexible (and practical). So I'm uncertain what concepts are 
changing regularly.



>> 3rd question, related, is if it's needed and planned work for GRUB to know 
>> about subvolid such as (hd0,gpt5,sv218)
>> so that it can directly locate a subvolume regardless if it's been moved or 
>> renamed or if the default subvolume has been changed.
> 1) Between brackets is disk names and changing this would result in
> utter mess. On other hand something in second part is possible. E.g.
> (hd0,gpt5):btrfs,<parameters>/
> is possible.

That seems reasonable.

> But I don't see why one should handle supporting renaming subvolumes
> transparently. It would be like having to handle file renames
> transparently.

It's more like having to handle partition name changes transparently, which of 
course is the current behavior. Even if I were to move the partition to 
different blocks on a disk, as long as its partition number is consistent, it's 
locatable, including by GRUB, regardless of partition name.


> Should one reference all files in all config files in all
> software by inode numbers, just in event it gets renamed?

I don't think the file analogy works very well for subvolumes. Subvolumes have 
some behaviors like folders, and some behaviors like LVs, and some behaviors 
like entirely unique file systems volumes.

It might be  possible to refer to subvolume UUID, which is also unique. I 
haven't tested if mount works with this.


Chris Murphy