grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: booting btrfs


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: booting btrfs
Date: Sun, 13 Oct 2013 21:47:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8

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? I don't know off hand if each member disk, 
>>> or subsequently added disks, each have this 64KB pad or just the first 
>>> member.
>>>
>> This is besides the point. I'm fine to discuss such things but in a
>> separate thread.
> 
> 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.
> 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.
But I don't see why one should handle supporting renaming subvolumes
transparently. It would be like having to handle file renames
transparently. Should one reference all files in all config files in all
software by inode numbers, just in event it gets renamed?
> 
> 
> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]