Thoughts on the ext4 panic
Posted Oct 29, 2012 15:43 UTC (Mon) by nix
Parent article: Thoughts on the ext4 panic
introducing unchecksummed data into the journal
More serious than being unchecksummed, this was a modification made outside all journal transactions. That's... not supposed to happen.
it is not at all clear what the best response should be when journal checksums fail to match
It is clear that the current response is far suboptimal, but the right approach (aborting only those blocks with corrupted checksums) isn't implemented, and since it relates only to an obscure feature that basically nobody turns on, implementing it hasn't been considered terribly important.
it has already been revised once
Twice. Eric complexified the patch, then Ted simplified it again.
the media coverage of this bug was clearly out of proportion to that bug's impact
Many media outlets employ editors and writers who, almost beyond belief, are not trained in kernel programming.
In other news, a degree of wind expected on the US east coast today. :)
the addition of features to the ext4 filesystem
... surely doesn't apply here. This feature has been around for years and years, about as long as ext4 itself. Even this bug caused no more than the loss of a few log entries and half a dozen emails. fsck cleaned up the mess remarkably well, well enough that I thought nothing of smashing the corruption hammer into the same filesystem over and over again while helping characterize the bug.
to post comments)