On 4 Nov 2012, Linus Torvalds stated: > Perhaps notable just because of the noise it caused in certain > circles, there's the ext4 bitmap journaling fix for the issue that > caused such a ruckus. It's a tiny patch and despite all the noise > about it you couldn't actually trigger the problem unless you were > doing crazy things with special mount options.
It also helps if you reboot during umount. Which is also crazy (says the man who's still doing it). But the *real* problem is the way journal_async_commit uses a journal checksum failure as an indication that the commit was interrupted as long as there is no following commit block, which as the comment in fs/jbd2/recovery.c:do_one_pass():JBD2_COMMIT_BLOCK says, is going to lead to an incorrect conclusion of interrupted commit and a successful remount whenever commit N is corrupt and commit N+1 is interrupted (e.g. by some loony rebooting or powerfailing during umount). This problem seems to be intrinsic to journal_async_commit to me, since it repurposes journal checksums to do a second job of missing-commit- block detection, which pretty much means that *actual* checksum failures, i.e. kernel bugs or corruption at writeout time, go undetected, just as they do when journal checksumming is off -- but they *also* mean that errors computing the checksum can go undetected. And since journal checksumming is rarely used, such bugs can persist for a relatively long time. All of this means that journal_async_commit is *more* likely to cause a no-warnings remount of a corrupted filesystem that really needs fscking than is a filesystem using a normal non-checksummed journal. And that, to me, is the really dangerous part. If you know the fs is corrupt, you can fsck it and all is well, after a bit of flak: you won't overlook it. If you don't know the fs is corrupt, you run a substantial risk of making things much much worse before the problem escalates from ext4 errors in a log you never read into -EIO. (I happened to be reading that log because I was trying to reproduce the nsm lockd bug. But normally? Yeah, I spend all my time reading the kernel log, doesn't everyone?) I'd apologise for causing all the fuss, but it wasn't me who decided to submit it to Phoronix (actually I suspect Michael Larabel just read the list and everything snowballed from there). -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
