El mar, 01-07-2008 a las 22:48 +0200, Robert Millan escribió: > On Tue, Jul 01, 2008 at 08:42:39PM +0200, Javier Martín wrote: > > partition as "unrecognized" and then I had to specifically request it to > > be mounted as ext2 with a possible --ignore-incompatible flag, > > A --ignore-incompatible flag doesn't sound like a nice thing to do; it means > we're passing our own problem to the user instead of solving it. We don't have any "problem" to pass to users: ext4 is not supported and thus we do the Right Thing (tm) in patching our ext2 driver so that it won't try to read a filesystem it cannot. However, given Pavel's and others' objections, I suggested the addition of an user override to it. Thus, the user will have to knowingly force the system to interpret the filesystem with its current code, and accept any failures he might get, instead of the current behaviour of having the FS mounted automatically without checking incompatibilities (and then getting the errors anyway).
Furthermore, the possibility of accidentally adding an incompatible feature is not exactly high: for an ext3 FS to get one of the ext4 flags, one has to explicitly mount it as "ext4dev" (usually installing or hand-compiling the module before, because most distros don't include it by default) _and_ create new files on it. Then and only then will the FS gain the extents flag. > > Though, if non-essential stuff needs to be implemented, please take into > account that we're really pressed for space in ext2.mod (and try to use a > separate module for that). > The proposal (a patch which is essentially under ten lines of code long) could _avoid_ the implementation of format compatibility checks in all the inode-handling functions, since after passing the compatibility check we know the format we'll encounter is at least ro-compatible with our capabilities, or the user is braced for the possible errors. With the current implementation, an unawares user could be flooded by inode format errors becase, for example, an ext4 FS got mounted by our ext2 driver. The override proposal is not implemented in the current patch, but it could be as simple as an environment variable. Consider this case, with (hd0,1) an ext3 /boot partition that was accidentally converted to ext4 and then got a file copied to it (the 2.6.26-rc2 kernel), then gaining the extents flag: grub> ls (hd0,1)/ error: unrecognized filesystem grub> set ext2_options=ignore_incompatible grub> ls (hd0,1)/ kernel-2.6.24-r1 kernel-2.6.26-rc2 grub> kernel (hd0,1)/kernel-2.6.26-rc2 root=/dev/sda5 error: file not found # (I dunno what error "bad inode" is) grub> kernel (hd0,1)/kernel-2.6.24 root=/dev/sda5 [Linux-bzimage, 0x100000] grub> boot
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