grub-devel
[Top][All Lists]
Advanced

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

Re: workaround install boot on btrfs with windows partition scheme


From: Chris Murphy
Subject: Re: workaround install boot on btrfs with windows partition scheme
Date: Sun, 2 Nov 2014 15:19:43 -0700

On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov <address@hidden> wrote:

> В Sat, 1 Nov 2014 19:34:56 -0600
> Chris Murphy <address@hidden> пишет:
> 
>> 
>> On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov <address@hidden> wrote:
>>> 
>>> I still believe this is more flexible; in particular, /boot/grub on
>>> btrfs has problems with unwritable grubenv (quite a few people are hit
>>> by this now, when openSUSE defaults to single btrfs partition) so
>>> having separate /boot as ext2 makes sense.
>> 
>> Hmm, interesting. What's the nature of this problem with grubenv on btrfs? 
>> Is the current grubenv code expecting the file to be contiguous, and due to 
>> COW on btrfs it ends up not being contiguous? Does setting xattr +C on 
>> grubenv fix the problem?
>> 
> 
> btrfs code does not execute hooks so block list collection always gives
> empty block list and file size 0. That's unfortunate, because it also
> means e.g. progress display is not possible.
> 
> btrfs data is checksummed so overwriting it would involve recomputing
> checksums and replacing them. It is not possible to do in place because
> checksums are checksummed themselves ... you get the idea.
> 
> btrfs can be on multiple devices so we cannot even expect grubenv to be
> located on single disk; and blocklists simply do not support it.
> 
> btrfs can be compressed so you cannot even expect that new data will
> fit into existing space.

All the more reason for it to go in its own partition, rather than in some tiny 
area, or multiple tiny areas in filesystems. It's taken years to coordinate 
these things.


> 
>> Having separate /boot on ext was fine as a short/medium term work around, 
>> but /boot on btrfs has use case benefits so it really needs to work 
>> eventually.
>> 
> 
> So far nobody suggested solution for grubenv on unwritable location.
> Not to mention implementation …

Put grubenv on 0xEA/BIOSboot as well. It's GRUB's partition it can put anything 
it wants there, exactly where it expects to always find it. No coordination 
with filesystem groups required. I don't see any of the fundamental behaviors 
about Btrfs you're referring to changing anytime soon because it's simply how 
the fs works, they aren't bugs. So either GRUB gets its own partition with 
exclusive domain, or it continues to be hobbled by filesystem dependencies like 
needing to be forced installed on ext, can't be installed at all to XFS, and 
barely fits in 64KB on the Btrfs pad.

It's not like there's a shortage of partitions. And for future proofing this, 
enable GRUB to use more than one such partition. So if there's a 1MB 
0xEA/BIOSboot and one day more space is needed, just add another one.


Chris Murphy


reply via email to

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