From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xknqp-0002du-1Y for mharc-grub-devel@gnu.org; Sun, 02 Nov 2014 01:37:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xknqh-0002dh-Q3 for grub-devel@gnu.org; Sun, 02 Nov 2014 01:37:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xknqc-0007ZH-40 for grub-devel@gnu.org; Sun, 02 Nov 2014 01:37:11 -0400 Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:63326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xknqb-0007Z4-QJ for grub-devel@gnu.org; Sun, 02 Nov 2014 01:37:06 -0400 Received: by mail-lb0-f170.google.com with SMTP id 10so7881840lbg.29 for ; Sat, 01 Nov 2014 22:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=OcU8XtCokhfGGqpuzbiaLQ5TXefJGg3+VJSWqcENcjE=; b=dGrRF0OHpmbZqA5qRlBb+pa6E+5SrEmqb60w5Wl5rAzOJWzEK0Am2/MsIjMTggZlsj me+wE7MSuQaKbtzcSsm03mBCJZZiRozpZzF8tEunQWA+lbVORrkvYpR7unykE8LO5che xPbE/XrDcE+pSVFpEdtBI6raQj3FbK91LW4R5+AFogdZythUQcM6TMBaUQAIPEyJyBgq LJSAmuUGtTm5BZrvPK+nklzvUfURKkj+fnyzYOLJidMGn+rDI9cykQrj7nSSDuAhLbBT ZUGWjmi0vnbVdFPhrFhin1mUtHQmYTyuBYeL1UbiA3Doy1PLs/PpD2+tQPPeLzqN3Ai5 KfKg== X-Received: by 10.112.247.43 with SMTP id yb11mr39461980lbc.51.1414906624033; Sat, 01 Nov 2014 22:37:04 -0700 (PDT) Received: from opensuse.site (ppp91-76-139-38.pppoe.mtu-net.ru. [91.76.139.38]) by mx.google.com with ESMTPSA id x7sm5034050lad.13.2014.11.01.22.37.02 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 22:37:03 -0700 (PDT) Date: Sun, 2 Nov 2014 08:37:01 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: workaround install boot on btrfs with windows partition scheme Message-ID: <20141102083701.56e93821@opensuse.site> In-Reply-To: <128E41CD-F94A-4CAF-A90E-C6F007AFE28A@colorremedies.com> References: <20141030083243.GA7083@linux-dsax.tai.apac.novell.com> <128E41CD-F94A-4CAF-A90E-C6F007AFE28A@colorremedies.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22a Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 05:37:17 -0000 =D0=92 Sat, 1 Nov 2014 19:34:56 -0600 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wrote: > >=20 > > 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. >=20 > 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 g= rubenv fix the problem? >=20 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 eventu= ally. >=20 So far nobody suggested solution for grubenv on unwritable location. Not to mention implementation ...