El mar, 01-07-2008 a las 12:25 -0400, Pavel Roskin escribió: > On Tue, 2008-07-01 at 18:08 +0200, Robert Millan wrote: > > > > 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. > > > > I think we should be more conservative here, and only reject a filesystem > > when we know _for sure_ that GRUB won't be able to access it. Otherwise > > we may be disabling filesystems that are probably fine. > > 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. > > 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. > 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.
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
