From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VVahb-00038o-NC for mharc-grub-devel@gnu.org; Mon, 14 Oct 2013 01:28:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVahU-000385-5G for grub-devel@gnu.org; Mon, 14 Oct 2013 01:28:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVahO-0002H9-Ar for grub-devel@gnu.org; Mon, 14 Oct 2013 01:28:16 -0400 Received: from mail-lb0-x232.google.com ([2a00:1450:4010:c04::232]:49535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVahN-0002Gw-UP for grub-devel@gnu.org; Mon, 14 Oct 2013 01:28:10 -0400 Received: by mail-lb0-f178.google.com with SMTP id z5so5126848lbh.23 for ; Sun, 13 Oct 2013 22:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=qH0anNK3oGJzPsIk2g132nj69Uof9MM9aAUFpHcISlQ=; b=unMQWEsLIJr5OTRxgjNkfROqns5ADASsrDo9F7SKAwg4aatp6zTuw1YA8bX6zKhjOU jGSG3difd0F/3Lkd4fpdekam4b2eG5D8Q7JBa+mIVfv/C4fuAJoqbMjJn7u40Cl2Sv1L gmba7l+l4FIC0qrj1+pEO1jEi1sU3cqVMSrIlyGV7M54HwVf+FWwX0QBJk91HKoAVANC qK3G4ihad2/811BckEaW6Ekza4VI7oKN9QXdGE/blkAFxAeQ85E0k9wa/AzUx669t+TM tFjjiid03o+jUeuFHSCg66mAt0oSMAwA+nbFtBoD7LvD2nO2aiQD6L1Twn9EgW/Fsoq9 jVsA== X-Received: by 10.152.22.131 with SMTP id d3mr269035laf.35.1381728488450; Sun, 13 Oct 2013 22:28:08 -0700 (PDT) Received: from opensuse.site (ppp91-76-150-246.pppoe.mtu-net.ru. [91.76.150.246]) by mx.google.com with ESMTPSA id ao4sm57905444lac.1.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 13 Oct 2013 22:28:07 -0700 (PDT) Date: Mon, 14 Oct 2013 09:28:07 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: booting btrfs Message-ID: <20131014092807.6917958c@opensuse.site> In-Reply-To: <339EF7EB-F50A-47F6-99BA-F46ABFECCF74@colorremedies.com> References: <0C284942-C2D0-4520-93B1-3982E6AA38DF@colorremedies.com> <525AF8CD.7050100@gmail.com> <525B2D55.8060502@gmail.com> <339EF7EB-F50A-47F6-99BA-F46ABFECCF74@colorremedies.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; 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::232 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: Mon, 14 Oct 2013 05:28:22 -0000 =D0=92 Sun, 13 Oct 2013 17:58:41 -0600 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Oct 13, 2013, at 5:31 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko <= phcoder@gmail.com> wrote: >=20 > > On 13.10.2013 22:59, Chris Murphy wrote: > >>=20 > >> How does one create a subvolume without a name? All subvolumes have ha= d ID's since at least 2008, and it's been possible to mount by name or ID f= or 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 > The top level subvolume (id 5) is likely reported as "/" just like is the= case when mounting any file system. >=20 > It's possible that changing the default subvolume causes this same behavi= or rather than mount reporting the full path. I haven't tested this. >=20 No, it is inconsistent behavior for named subvolume and subvolume ids mounts. For named subvolume btrfs internally mounts top level directory (actually using subvolid=3D0 for this internal mount) and then performs equivalent of bind mount on subvolume. For subvolid it actually sets root of filesystem to subvolume during mount. As mountinfo displays path relative to filesystem root, it is always "/" if subvolid was used. I do not know if there are practical differences between the two. > >=20 > >> 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. >=20 > That's not possible. It had to be this way to support snapshotting. A sna= pshot is a subvolume. The subvolume only appears as a directory, in reality= the directory links to the subvolume which are a completely separate btree= and analogous to a whole separate file system. And since its a separate fi= le system, the inode numbers start over. Conversely a directory is just an = item like a file in the tree, it's not a tree in its own right, which a sub= volume is. >=20 > > On both ZFS and btrfs as far as GRUB is concerned are directories with > > just slightly different structure. >=20 > Understood, but I think this is less ideal. It offers less leverage and u= sage of the file system as a boot, even as rootfs, file system. >=20 > > Why would numbers be preferable to names? >=20 > Without the use of subvolid=3D we either have to always use full paths f= or subvolumes (instead of relative), or we can't use btrfs set-default to c= hange the default subvolume. If the paths to subvolumes are relative to the= default subvolume, then changing the default subvolume breaks booting. And= full paths could become rather cumbersome, since the hierarchy is effectiv= ely unlimited. >=20 Why full paths are cumbersome? The mount -o subvol=3Dpath/to/boot /dev/sdX /mnt vi /mnt/grub/boot.cfg is 100% equivalent to mount -o subvolid=3D0 /dev/sdX /mnt vi /mnt/path/to/boot/grub/boot.cfg And GRUB is concerned only with value of $prefix. So as long as grub-install can resolve path name of /boot/grub to full path from btrfs root including subvolumes it is OK. And to use subvolume ID you will need to detect that path is on subvolume anyway. > Today, maybe it's not the best scenario to have two or three OS's install= ed on one btrfs volume, in separate subvolumes, each with hundreds of snaps= hots. But it's designed to enable such a workflow once it's stable. I think= using full paths (always relative to the top level subvolume which never c= hanges even if the default subvolume is changed) is fine in the near term. = And it may be some workflows simply prefer the (human user) transparency th= at comes with full paths. But from my perspective, a fixed number means I c= an completely reorganize a hierarchy with no other changes. >=20 Could you please provide example of what you mean here? > > The rename may very well be > > intentional in order to make other OS and/or version to boot. >=20 > Yes, and I'm not suggesting the end to supporting either full path, or re= lative path referencing of subvolumes. Just that it's also possible to use = subvolid. >=20 What about grub-mkconfig? It does not pass explicit subvolume if it is not present in mountinfo, which means a) if someone changes default subvolume it will end up mounting wrong root and b) it breaks if mount by subvolid is used.