From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KDkoH-0006pK-1s for mharc-grub-devel@gnu.org; Tue, 01 Jul 2008 14:42:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDkoF-0006n9-06 for grub-devel@gnu.org; Tue, 01 Jul 2008 14:42:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDkoE-0006mV-91 for grub-devel@gnu.org; Tue, 01 Jul 2008 14:42:34 -0400 Received: from [199.232.76.173] (port=36615 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDkoE-0006mS-3M for grub-devel@gnu.org; Tue, 01 Jul 2008 14:42:34 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]:11419) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KDkoE-0007JL-41 for grub-devel@gnu.org; Tue, 01 Jul 2008 14:42:34 -0400 Received: by ug-out-1314.google.com with SMTP id l31so545636ugc.48 for ; Tue, 01 Jul 2008 11:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=QDCuq6wmlLnICdLVTV95D4PYkd8pRPIoICsReJ+X6/o=; b=q++w/aBXqtxvnAqWcvv1NXxk3DKfmNOuxd9lJnHMFGhDtgIwMyqXbhR4nHtvl6dAJ8 1GYVFAbc9ifh9eMvNZ2xd3y+9R+SmKtLStez7uEybDrBW4iVXfxu2oZdoeuJZW/G2eLD FQ1eV7FkuUn4jx99wS4h8TodIktKN5vX1bq7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=J6hfquU08kqXP8mD0eZ+kkRnb8gKPk3eLDDQ7wUzTE9RAC+xVHey0Kh6i0qF8hqKr0 OAeAfyzMd76YpuIRmmD3JUFgiW6T844Ydu0kJXP8fmlO49F62ssTH4HyZn63gvttWJQJ aJlXQdjRW1IFbBdTNlSDe8gzUIc9LXupR2CYk= Received: by 10.67.106.13 with SMTP id i13mr541547ugm.37.1214937751736; Tue, 01 Jul 2008 11:42:31 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id 19sm4477845ugl.66.2008.07.01.11.42.29 (version=SSLv3 cipher=RC4-MD5); Tue, 01 Jul 2008 11:42:30 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <1214929545.13432.19.camel@dv> 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> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xZvwxCMLn0nw1rrkxNgT" Date: Tue, 01 Jul 2008 20:42:39 +0200 Message-Id: <1214937759.9353.64.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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 18:42:35 -0000 --=-xZvwxCMLn0nw1rrkxNgT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El mar, 01-07-2008 a las 12:25 -0400, Pavel Roskin escribi=C3=B3: > On Tue, 2008-07-01 at 18:08 +0200, Robert Millan wrote: >=20 > > > We must not quit if the journal flag is set, even if we don't handle > > > it. grub-setup runs in a active system, the journal wouldn't be empty= . > > > If we just quit, we can't even install. > >=20 > > I think we should be more conservative here, and only reject a filesyst= em > > when we know _for sure_ that GRUB won't be able to access it. Otherwis= e > > we may be disabling filesystems that are probably fine. >=20 > I agree. Rules for read-only access should be more permissive than > those for read-write access. Rules for bootloader read-only access > should be relaxed even more. >=20 > For example, we don't really care about permissions and timestamps. It > would be nice to get them right, but failure to boot because of a > nanosecond timestamp would be too much. Likewise, we don't care if some > files are compressed or use a file size representation we don't support > and long as the files we need don't use it. >=20 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. --=-xZvwxCMLn0nw1rrkxNgT Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASGp6n6Sl+Fbdeo72AQJPbRAAmZWFvQ2IEUARI8Hin3SkT4OP6GU4Su+H 0VTN5JxvPCqgvUr4VmXN4mktkLPaJ60XiGrHa3DbPUSTZ5fQ3b8L+Yi3OXU6lQeU LENdr1xnt/GrCFXAfC3bic0QIcc9D+4p5YuImZ//9UcVvwt6jrCSOqsF5SC+YAC8 nShdqbyAg86eHPHegnxsaAeyNrEHEGhWTowomIz7nw0fJw5g7ybrpFpdgDnunzld p+aEUjHC1mDE1LGEu+gSljY43XbxUFv3yz6VFo2M7HW3ebSFfYAoxCH1DsYGWc2g scC0uswFPLdU9ZYSlIpAvYM8E/ypDil69reeWUylrBvSpAWglHAubaEH67SgelfV Uei9iySFurf2mx4tajQsZQ5iDwv+cJVxJdNiNRGrrXQAVw7HejstNqnAMQnV809j xXLxJLUihtV3y7r0GwGUoxguBG3RMWRXgn1rmjNpXn4m0iUViItHRQI6zfzsBTu5 X7TFcQ+PWW240Ey0UyBLBeyphwnHKMsqtxP/e5oJZewl/D9u9p0Zm82CMh4PQ3tJ r7/CNCCn1MtSsh8XHSqLB3ptP17LjIvsvwy/niesDt/MrtKwVY/A4Q607xXLFU50 EMgkW/X6c55z8KMBxtb+kPUbn3FCWsl0QpoG4dcdgQ173pRP9HqojOm/usXwhMQt QP4SufQ1Fm0= =0+LG -----END PGP SIGNATURE----- --=-xZvwxCMLn0nw1rrkxNgT--