> I think corrupted filesystem shouldn't cause panic - maybe ext2_find_entry
> should just log this with printk and return NULL? From what I was looking
> at the code, this is a legitimate return value indicating an error.
The "ext2_find_entry: buffer read pointer is NULL" problem doesn't look
like a filesystem corruption; having eyeballed the code in
fs/ext2/inode.c, it looks like a "should never happen" condition.
Remy? Do you agree?
i would say that it is. recently i had an ext2fs problem (which may not
have been related to the ext2fs code itself) in which the root inode,
directory, and superblocks all got overwritten with garbage. had
ext2fsck plunged ahead and tried to fix things, it would almost certainly
have caused me to lose a *lot* of files. as it was, it was laborious but
possible to rebuild the missing parts and restore my filesystem without
the loss of anything irrecoverable. i'd really rather have the kernel
panic and stop rather than blindly trying to continue, possibly making
things worse.
what would have been *really* cool would have been for ext2fsck to have
detected this condition, and gone into some sort of interactive disk
editing mode in which it could have been fixed easier than with perl
scripts and lde.
Well, there is also debugfs, which is useful for doing interactive
manipulation of the ext2 filesystem structures. I personally don't
think that having e2fsct call into it by default when there is a
filesystem problem is all that useful, since if you know about debugfs,
you can run it yourself; and if you don't, you probably don't know
enough about debugfs that it will simply be frightening, and you may end
up doing more harm than good.
- Ted