From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VVRde-0005zd-GW for mharc-grub-devel@gnu.org; Sun, 13 Oct 2013 15:47:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVRdX-0005yy-M9 for grub-devel@gnu.org; Sun, 13 Oct 2013 15:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVRdR-00071U-M1 for grub-devel@gnu.org; Sun, 13 Oct 2013 15:47:35 -0400 Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:42639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVRdR-00071F-EO for grub-devel@gnu.org; Sun, 13 Oct 2013 15:47:29 -0400 Received: by mail-ea0-f169.google.com with SMTP id k11so2980486eaj.0 for ; Sun, 13 Oct 2013 12:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Hel/zZyngmHk1qDnghUidAaeiUgCGCTRagcfg4/XsMc=; b=DxvWXsjyOmPU41dol635qJsjSTx184qIlhvxUc38TtdddgTUiIwAY2EhL118D1TXt0 XDoc27R+LoTnlZtHL3YDX3/p2wuMmTAX2n5vCi9V0VBA2CBz2OF7MC0Y9s3ePHdwu+5A CnOlPcBthX5jxM0IUD09zGHdvQStL+Xh4FEFFGNAdWUHElDdrK3576EC6bP/MSYWzdaz lDPeGBZMo5jrZ/7xU+A/S7zveZz6KAgTZ/DsOArLhSzqgkCPneVrWZ7iHvF7VVaiIk7J zml+hV0e2a2kaj5WZ5TTdYFzgehbQZI8eYi59DbeybJV0lNs49CSwxL+5v+qz3OaMAJj DAHA== X-Received: by 10.14.246.11 with SMTP id p11mr50547857eer.9.1381693648063; Sun, 13 Oct 2013 12:47:28 -0700 (PDT) Received: from [192.168.1.113] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id l49sm59915830eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Oct 2013 12:47:27 -0700 (PDT) Message-ID: <525AF8CD.7050100@gmail.com> Date: Sun, 13 Oct 2013 21:47:25 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: booting btrfs References: <0C284942-C2D0-4520-93B1-3982E6AA38DF@colorremedies.com> In-Reply-To: <0C284942-C2D0-4520-93B1-3982E6AA38DF@colorremedies.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2WWVBWSPRBPBXBUHPMPTR" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::229 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, 13 Oct 2013 19:47:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WWVBWSPRBPBXBUHPMPTR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13.10.2013 20:04, Chris Murphy wrote: > On Sep 26, 2013, at 4:15 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko= wrote: >=20 >> 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 fi= rst member. >>> >> This is besides the point. I'm fine to discuss such things but in a >> separate thread. >=20 > 2nd question is whether additional things are needed for /boot on btrfs= =2E Using qemu/kvm and vbox I've tested maybe 6 virtual disks using btrfs= single, raid0, raid1, and raid10 configurations, and consistently GRUB c= an boot /boot as a subvolume. I don't know how resilient this is as the f= ile system is used and chunks end up on different devices or if this is s= ufficiently abstracted that it doesn't matter and just works; including i= f devices are removed and added. >=20 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 k= now about subvolid such as (hd0,gpt5,sv218) > so that it can directly locate a subvolume regardless if it's been move= d 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,/ 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? >=20 >=20 >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2WWVBWSPRBPBXBUHPMPTR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlJa+M0ACgkQNak7dOguQgl11wD/av+PFm6gGfKyYam1tp9mAyTr RFMJGa946cNo8Dr1RTcBAKbVgvuDosNNWVeN+8d47ihMgpg5JOW+ManwlUIuSaPE =KoaG -----END PGP SIGNATURE----- ------enig2WWVBWSPRBPBXBUHPMPTR--