From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VVV8W-0000FC-Aw for mharc-grub-devel@gnu.org; Sun, 13 Oct 2013 19:31:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVV8P-0000EB-P6 for grub-devel@gnu.org; Sun, 13 Oct 2013 19:31:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVV8K-0005Pd-EA for grub-devel@gnu.org; Sun, 13 Oct 2013 19:31:41 -0400 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:63675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVV8K-0005PZ-2t for grub-devel@gnu.org; Sun, 13 Oct 2013 19:31:36 -0400 Received: by mail-ea0-f180.google.com with SMTP id h10so2958508eaj.25 for ; Sun, 13 Oct 2013 16:31:35 -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=/6+AGJxYryHqJiVDWesmESti1EoiUJWFw1twQ9DlItg=; b=tkK1AqLXKMCoP4h2eHMPGuJXkX0sz0OtB3/OdJHu5vUti0ilnbh/7q0hzxE0DsxWW2 D9pJ/PUfW4Q/vXFFNg4PWhk0KVZX5bQPsThdrtywqbedxu4YKOPUcGWGuvA5+tgx9Oxp mOpn2P3xQnfyfT75KrAmA/QDzIQK/ylzh0b4mUdFVB+rPLRw4DySGx8ZD+ptaqW4zCAU REl9BbHJC+rGpBLaUaZBCqk6dbmIm03OClS3Tagi0076WFnGRhmxf8abtpEjGJgfRzJW 8zmd4Xh/3s6yN4xtUH99lAmKETy7/fMQ0wSWFH4DfAUkQn+n7Eb9KnswX9UUXr1WZeZ4 VS1Q== X-Received: by 10.15.35.196 with SMTP id g44mr51588189eev.18.1381707095179; Sun, 13 Oct 2013 16:31:35 -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 m54sm145972138eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Oct 2013 16:31:34 -0700 (PDT) Message-ID: <525B2D55.8060502@gmail.com> Date: Mon, 14 Oct 2013 01:31:33 +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> <525AF8CD.7050100@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2FLMEARQCMESODCFKAHGV" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::234 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 23:31:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FLMEARQCMESODCFKAHGV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13.10.2013 22:59, Chris Murphy wrote: >=20 >=20 > On Oct 13, 2013, at 1:47 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko= wrote: >=20 >> On 13.10.2013 20:04, Chris Murphy wrote: >>> On Sep 26, 2013, at 4:15 PM, Vladimir '=CF=86-coder/phcoder' Serbinen= ko wrote: >>> >>>> On 26.09.2013 22:51, Chris Murphy wrote: >>>>> >>>>> Open question is if on BIOS hardware, if a 1MB BIOSBoot is preferre= d over the 64KB Btrfs bootloader pad? >=20 >=20 > What about this question? >=20 BIOS Boot partition is prefered. Currently btrfs 64K part isn't used to whole potential. It will change. >=20 >>> 2nd question is whether additional things are needed for /boot on btr= fs. 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. >>> >> 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 concep= ts >> change so regularly and we get no notification or consultation from >> devs, we should keep code as-is and handle, that is handling sane case= s >> and skip the others, like subvolumes without a name. >=20 > How does one create a subvolume without a name? All subvolumes have had= ID's since at least 2008, and it's been possible to mount by name or ID = for quite a few years at least as well. >=20 Then this illusion was created by the /proc/mountinfo listing mounted subdirectory as "/" when mounted by id (or something like that). >=20 >=20 >>> 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 mo= ved 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. >=20 > That seems reasonable. >=20 >> But I don't see why one should handle supporting renaming subvolumes >> transparently. It would be like having to handle file renames >> transparently. >=20 > It's more like having to handle partition name changes transparently, w= hich of course is the current behavior. Even if I were to move the partit= ion to different blocks on a disk, > as long as its partition number is consistent, it's locatable, includin= g by GRUB, regardless of partition name. >=20 moving blocks is analogous to defragging a file which is also supported. Filesystem label works on different level, namely it's part of fs. In msdos partition scheme partitions have no name other than a numerical ID.= >=20 >> Should one reference all files in all config files in all >> software by inode numbers, just in event it gets renamed? >=20 > I don't think the file analogy works very well for subvolumes. Subvolum= es have some behaviors like folders, and some behaviors like LVs, > and some behaviors like entirely unique file systems volumes. I feel like subvolumes are glorified folders and would have prefered directories becoming more powerful rather than having a completely new concept. On both ZFS and btrfs as far as GRUB is concerned are directories with just slightly different structure. Why would numbers be preferable to names? The rename may very well be intentional in order to make other OS and/or version to boot. >=20 > It might be possible to refer to subvolume UUID, which is also unique.= I haven't tested if mount works with this. >=20 >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2FLMEARQCMESODCFKAHGV 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/ iF4EAREKAAYFAlJbLVUACgkQNak7dOguQgkZIwD/YYnbYwolHncE+saiSXgJ2D0K NUMB4jQ8985fi/be0c4A/jfsRZvpUXZJyJlVHT4f2RW9hRAChxYtOjbAamxEzuUa =9YF7 -----END PGP SIGNATURE----- ------enig2FLMEARQCMESODCFKAHGV--