Re: booting btrfs

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4077 bytes --]

On 13.10.2013 22:59, Chris Murphy wrote:
> 
> 
> On Oct 13, 2013, at 1:47 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:
> 
>> On 13.10.2013 20:04, Chris Murphy wrote:
>>> On Sep 26, 2013, at 4:15 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> 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?
> 
BIOS Boot partition is prefered. Currently btrfs 64K part isn't used to
whole potential. It will change.
> 
>>> 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.
> 
Then this illusion was created by the /proc/mountinfo listing mounted
subdirectory as "/" when mounted by id (or something like that).
> 
> 
>>> 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.
> 
moving blocks is analogous to defragging a file which is also supported.
Filesystem label works on different level, namely it's part of fs. In
msdos partition scheme partitions have no name other than a numerical ID.
> 
>> 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.
I feel like subvolumes are glorified folders and would have prefered
directories becoming more powerful rather than having a completely new
concept.
On both ZFS and btrfs as far as GRUB is concerned are directories with
just slightly different structure.
Why would numbers be preferable to names? The rename may very well be
intentional in order to make other OS and/or version to boot.
> 
> It might be  possible to refer to subvolume UUID, which is also unique. I haven't tested if mount works with this.
> 
> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]