All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: workaround install boot on btrfs with windows partition scheme
Date: Sun, 2 Nov 2014 08:37:01 +0300	[thread overview]
Message-ID: <20141102083701.56e93821@opensuse.site> (raw)
In-Reply-To: <128E41CD-F94A-4CAF-A90E-C6F007AFE28A@colorremedies.com>

В Sat, 1 Nov 2014 19:34:56 -0600
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov <arvidjaar@gmail.com> 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.

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


  reply	other threads:[~2014-11-02  5:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30  8:32 workaround install boot on btrfs with windows partition scheme Michael Chang
2014-10-30 12:42 ` Andrei Borzenkov
2014-11-02  1:34   ` Chris Murphy
2014-11-02  5:37     ` Andrei Borzenkov [this message]
2014-11-02 22:19       ` Chris Murphy
2014-11-03  5:36         ` Andrei Borzenkov
2014-11-03 19:36           ` Chris Murphy
2014-11-03 20:29             ` Andrei Borzenkov
2014-11-03 21:05               ` Chris Murphy
2014-11-04  5:50                 ` Andrei Borzenkov
2014-11-04  6:46                   ` Chris Murphy
2014-11-03  4:17   ` Michael Chang
2014-11-03 20:04     ` Chris Murphy
2014-11-04  4:50       ` Michael Chang
2014-11-04 18:21         ` Chris Murphy
2014-11-01 20:35 ` Chris Murphy
2014-11-02  5:27   ` Andrei Borzenkov
2014-11-02 22:11     ` Chris Murphy
2014-11-03  5:31       ` Andrei Borzenkov
2014-11-03 19:08         ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141102083701.56e93821@opensuse.site \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=lists@colorremedies.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.