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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
