On Tue, May 11, 2010 at 08:10:06PM -0500, Eric Sandeen wrote: > tytso@xxxxxxx wrote: > > On Tue, May 11, 2010 at 05:06:43PM -0500, Eric Sandeen wrote: > >> Theodore Ts'o wrote: > >>> Some kernels will crash if EOFBLOCKS_FL is set when it is it not > >> Is there a kernel fix to go with this, then? > > > > There will be; Dmitry sent a patch in the ext4 patch a while back. > > > > http://patchwork.ozlabs.org/patch/50469/ > > > > The fix to prevent the crash is tiny. The rest of the patch I need to > > review more carefully.... I'll get to it RSN. > > Ok sorry, I didn't put 2 & 2 together, there. :) > > Thanks for the reminder, To be clear, the fix to prevent the crash is: EXT4_ERROR_INODE(inode, "eh->eh_entries == 0 ee_block %d", ex->ee_block); to: EXT4_ERROR_INODE(inode, "eh->eh_entries == 0, iblock = %u" iblock); (this is the quick fix that we dropped into our production kernels, anyway; the problem is that ex is NULL, which means instead of marking the file system as needing repair, we Oops the system instead.) I just haven't had the time to analyze the rest of the patch yet. One of the things I've been considering is whether we should be trying to test for this failure at all. Is there a downside if EOFBLOCKS_FL is set when it shouldn't matter? Should we simply not try to check for the case? Or if we do check, should we just clear the flag and print a warning? The other side of the argument is if this is wrong, then either we have a kernel bug (see the first patch) or we had a hardware error, in which case something else might be wrong and maybe we should force a file system check. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
