From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VtwfY-0004Yg-Ca for mharc-grub-devel@gnu.org; Fri, 20 Dec 2013 04:46:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtwfW-0004WK-Gw for grub-devel@gnu.org; Fri, 20 Dec 2013 04:46:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtwfT-000885-Ur for grub-devel@gnu.org; Fri, 20 Dec 2013 04:46:54 -0500 Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:65218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtwfT-00087t-Pn for grub-devel@gnu.org; Fri, 20 Dec 2013 04:46:51 -0500 Received: by mail-ie0-f172.google.com with SMTP id qd12so2834495ieb.31 for ; Fri, 20 Dec 2013 01:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LeWOPLBmjCSfyShoiMwtGDjpTK68e0kjS1RaWsnauao=; b=BRTALjiKiC1cJehT5+VV2Q6OR7QgL7iLAXnzFChV50fHmsV3yGNnU3eipbYKNCRSNY yYYzZNgrcN5Odp0XfojRp3fW4vs5uh4k7c93t6/FfmuK7DSBOHjAAc12ly0FY5jsxlhC X8bigBtWD8LkhQtX9Pf+11XOuvs0O5d22nmKyy6zP+d2Ley7BE0fUyvscehTw1ybglQ6 vAliULVZjWQp2Qz/M1e9ppkpVF5kM3DJNfEL70iWfSgvEKY+V+qQMLNzbsXAY+H55ns3 yXo2S138Qf6X2MfPypgy12Bj0nByzXZiWTLKoDJEixaWanjckXCJqHn4B82gHhCOccui pZQA== MIME-Version: 1.0 X-Received: by 10.50.192.167 with SMTP id hh7mr7002699igc.3.1387532810911; Fri, 20 Dec 2013 01:46:50 -0800 (PST) Sender: mchang.novell@gmail.com Received: by 10.64.57.199 with HTTP; Fri, 20 Dec 2013 01:46:50 -0800 (PST) In-Reply-To: <52B3376A.7030301@gmail.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> <20131016065045.51027e72@opensuse.site> <526DB36A.7090201@gmail.com> <20131219201350.289470c7@opensuse.site> <52B3376A.7030301@gmail.com> Date: Fri, 20 Dec 2013 17:46:50 +0800 X-Google-Sender-Auth: zzft_8wthXoMxNrUTbkJQqXJS8s Message-ID: Subject: Re: booting btrfs From: Michael Chang To: The development of GNU GRUB Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22c 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: Fri, 20 Dec 2013 09:46:55 -0000 2013/12/20 Vladimir '=A6=D5-coder/phcoder' Serbinenko : > On 19.12.2013 17:13, Andrey Borzenkov wrote: >> =A7=A3 Mon, 28 Oct 2013 01:44:26 +0100 >> Vladimir '=A6=D5-coder/phcoder' Serbinenko =A7=E1=A7= =DA=A7=EA=A7=D6=A7=E4: >> >>> I changed in trunk to make / refer to real root and modified >>> grub-mkrelpath to follow the same convention, even if disk is mounted >>> with subvolid. >>> >> >> Can it cause compatibility issues? It means if config file that works >> for grub before this change will stop working after. So e.g. attempt to >> "configfile /file/from/partition/with/old/grub-mkconfig" will fail. >> > Normally I'd consider this a problem but the current behaviour is the > intended one, just back when the code was written thre were no changing > default yes >> May be subvolume support should use different syntax. Something like >> >> (hd0,1){sv=3Dsubvolume}/xxx >> (hd0,1){svid=3DNNN}/yyy >> > This would complicate the code a lot and commit us to maintaining it > long-term. Given that btrfs isn't clasified as stable, I consider this > behaviour change acceptable and it's better to handle this now rather > than perpetuating the issue. Please consider the case if a snapshot was taken against real root fs tree to a subvolume with SNAPSHOT_ID. With syntax above providing mount option support we can possibly boot that snapshot with this config. set root=3D(hd0,1){svid=3D} set prefix=3D($root)/boot/grub2 normal Without the syntax support it's almost impossible to do that. At lease I can't figure out any. Besides we may leverage that mount option support in grub-mount to test/develop and so on. For modern innovative file systems the mount option support is becoming necessary for dealing many different use cases. Thanks, Michael >> And continue to interpret old syntax as relative to default. >> >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >