From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KDl6O-0007Ek-LZ for mharc-grub-devel@gnu.org; Tue, 01 Jul 2008 15:01:20 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDl6M-0007E3-K7 for grub-devel@gnu.org; Tue, 01 Jul 2008 15:01:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDl6K-0007DA-O8 for grub-devel@gnu.org; Tue, 01 Jul 2008 15:01:18 -0400 Received: from [199.232.76.173] (port=42008 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDl6K-0007D6-Ht for grub-devel@gnu.org; Tue, 01 Jul 2008 15:01:16 -0400 Received: from c60.cesmail.net ([216.154.195.49]:64467) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KDl6K-0001qc-Ei for grub-devel@gnu.org; Tue, 01 Jul 2008 15:01:16 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 01 Jul 2008 15:01:14 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 28B02618F22 for ; Tue, 1 Jul 2008 15:01:14 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <1214937759.9353.64.camel@localhost> References: <889404A5CBB14C15B464EDBB1AE338A8@fz> <1214765178.6942.2.camel@localhost> <1214769230.6942.11.camel@localhost> <20080629211957.GD24784@thorin> <1214794971.9353.32.camel@localhost> <4868C017.8040004@isaac.cedarswampstudios.org> <1214827937.9353.43.camel@localhost> <20080701160827.GF6985@thorin> <1214929545.13432.19.camel@dv> <1214937759.9353.64.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 01 Jul 2008 15:01:13 -0400 Message-Id: <1214938873.15925.4.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 8bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub-probe detects ext4 wronly as ext2 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2008 19:01:18 -0000 On Tue, 2008-07-01 at 20:42 +0200, Javier Martín wrote: > Well, what can I say about this: INCOMPAT_* flags are so for a reason, > and they are telling us "don't even try to read this filesystem if you > don't implement this". It's true that _maybe_ the files we need don't > have extents, or compression, or other incompatible things, but then > we'd have to strengthen _every other_ routine in the driver, like those > that read inodes, guarding them against format changes that we have > probably ignored bypassing the incompatible features check. From the POV > of correctness I'd prefer to have a single point of "failure" in the > mount routine. > > Also, as a GRUB user I would find it quite strange that a filesystem > that is listed as recognized and whose files can be lsed would not let > me access a particular file because (insert unrecognized inode format > error here). I _would_ understand such errors if the system showed the > partition as "unrecognized" and then I had to specifically request it to > be mounted as ext2 with a possible --ignore-incompatible flag, because > then I would be knowingly doing something "risky", but the system should > not take such kind of decisions on its own unless the GRUB developers > _know_ about a particular flag and, after weighing the pros and cons, > specifically decide to ignore it (like the proposed patch does with > needs_recovery). However, doing that with possibly unknown future flags > is a no-go. OK, I wasn't arguing against your patch. I just tried to explain why we can relax some criteria compared to what a filesystem driver in a kernel would do. I actually agree with most of your arguments. -- Regards, Pavel Roskin