http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #16 from Theodore Tso <tytso@xxxxxxx> 2009-10-11 23:01:06 --- I've been trying to recreate this failure mode, and haven't had any luck. It looks like you are using LVM, so a really good thing to do is to use the e2croncheck script right after you reboot and login to the system. If it reports a clean filesystem, no worries. If it doesn't, then it would really be good to snapshot the output of dmesg to /tmp (I assume you have /tmp mounted as tmpfs) and e-mail it someplace safe, and e2croncheck can also be configured to e-mail the e2fsck output someplace safe as well. I'll note that that what Holger and Alexey are seeing are somewhat different. Holger seems to be seeing a problem after a clean shutdown after re-installing glibc from a build directory. That would imply orphaned inode handling getting screwed up some how, but I haven't been able to reproduce this on my systems. Alexey is seeing a problem after a crash/power failure, which implies some sort of issue with journal replay. One change that we did make between 2.6.31 and 2.6.32 is that we enable journal checksums by default. In theory if the hard drive is ignoring barriers, or is otherwise screwing up the journal I/O, we could get a journal checksum error that would abort the journal playback. That in theory could explain Alexey's symptoms, but he didn't report a journal checksum error message. So I really don't know what's going on right now. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
