From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VWHCQ-0003s1-HR for mharc-grub-devel@gnu.org; Tue, 15 Oct 2013 22:51:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWHCJ-0003ro-80 for grub-devel@gnu.org; Tue, 15 Oct 2013 22:51:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWHCD-00070I-Dm for grub-devel@gnu.org; Tue, 15 Oct 2013 22:50:55 -0400 Received: from mail-lb0-x230.google.com ([2a00:1450:4010:c04::230]:39897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWHCD-0006yf-4t for grub-devel@gnu.org; Tue, 15 Oct 2013 22:50:49 -0400 Received: by mail-lb0-f176.google.com with SMTP id y6so212175lbh.35 for ; Tue, 15 Oct 2013 19:50:48 -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=MGpGy7jS1M2UpEZqi4ZiSyyIytaM+CqRB6LDNOeSTfk=; b=rIcoyaHXVy+6x/TigMTgkFkSe1Fg2MxkxKJgbD7spqNk9V2lRG5s9g965D3dr4DECO +YOgMeiirvQnsbqGoae3s4rKAG0i0lkYUpyOEDQpWiF6fQnJdWmjG2d6sXzGpGuKK30o RdW/z5IsNS8q22LYLots9QDp7a9RKTemNaHOt4t9c+iaXZPV4Nmja/zxq6TXQGv6ObNZ iDGyLYD3J3hnToJl2/itK4m0D0Jjrc2uS6KhwA6FzhUhrDH160fba4/LeBGB984wTPDJ BzzbU7kgg5d7uK6NA1Twu3O4cV0+uhZtSFiisBSJVi7xOZBQ9LuTYeZ13fCi8UNUvyRT 2DKQ== X-Received: by 10.112.190.1 with SMTP id gm1mr698832lbc.30.1381891848009; Tue, 15 Oct 2013 19:50:48 -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 vx8sm49485474lbb.8.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 15 Oct 2013 19:50:47 -0700 (PDT) Date: Wed, 16 Oct 2013 06:50:45 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: booting btrfs Message-ID: <20131016065045.51027e72@opensuse.site> In-Reply-To: <4B3D9706-740B-49A2-8314-FF3893071A12@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> <20131014092807.6917958c@opensuse.site> <3D77CF50-285F-42C2-9325-47AC5ACF5FDC@colorremedies.com> <525C4615.5080803@gmail.com> <4B3D9706-740B-49A2-8314-FF3893071A12@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=KOI8-R Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::230 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: Wed, 16 Oct 2013 02:51:01 -0000 В Mon, 14 Oct 2013 14:20:14 -0600 Chris Murphy пишет: > > > Is there a way to detect that mountinfo gives garbage and somehow get > > where the real root points? > > I don't know. I've asked on linux-btrfs@. Instead of rebooting, I merely tried mounting without options after changing the default subvolume to a nested subvolume (one attempt subvolume in a subvolume, another a subvolume in a directory): in both cases /proc/self/mountinfo reports / as the root, not the full path or ID of the subvolume actually mounted. > > Somehow it seems like the mountinfo root field should return a block device and full path to the mounted subvolume or its ID. Currently it seems like a problem. > To quote one of btrfs developer (I had unrelated discussion on openSUSE list): --><-- This is a known problem, on my todo list, with a few non-working solutions. If you mount via subvol=/subvol then /proc/self/mountinfo will show 'subvol' as the mounted subvolume (4th column) 4 19 0:17 /subvol /mnt/ rw,relatime - btrfs /dev/sda15 rw,space_cache but if the subvolume is set-default and then implicitly mounted, mountinfo will not show that (that's the bug). --><-- That said, information can be obtained also using different means (btrfs utility or directly btrfs IOCTL). The question is to which extent we want to depend on existence of btrfsprogs.