Re: Linux 3.7-rc4

[Nix <nix@esperi.org.uk>]

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)