Slashdot Mirror
Data Corrupting ext3 Bug In Latest Linux 2.4.20
An anonymous reader writes "Andrew Morton alerted readers of the Linux Kernel mailing list today that ext3 in the 2.4.20 kernel has a new bug that can easily cause file data corruption at unmount time. The bug will only affect people using ext3 in "data=journal" mode, which fortunately is not the default... Full details can be read on KernelTrap."
I hope this bug doesn't corrupt the Slashdot datab%(@#LJASLO)aojda2
At the end of the link....
...
Andrew Morton wrote:>
>
> The fix is to only apply the optimisation to inodes which are operating
> under data=ordered.
>
That "fix" didn't fix it. Sorry about that.
Please avoid ext3/data=journal until it is sorted out.
WELL. It seems that the Open Source people ARE on top of it, but please, don't turn a Linux bug into a way to bash Microsoft. A better comment would have been "Hm. Well, they did screw up but they are fixing it".
Klez and ILOVEYOU all have fixes. A lazy person who doesn't update and patch will have an unsecure system regardless of if it runs Windows, Linux, BSD, Mac OS X, or ANYTHING.
And no, people who run Linux ARN'T smarter and WON'T update more consistantly, they just prefer Linux. And yes, newbies are more likely to be running Windows, but they wouldn't update no matter what OS they are on. And while newbies are more likely to run Windows, Gurus are NOT more likely to run *nix. It's getting old. You like Linux? Great. I'm sure that although things could be better you are very happy with your OS. I run Windows. Great. Although things could be better, I'm very happy with mine.
Unmounts happen at shutdown. You also need to unmount before scanning/fixing a filesystem. The whole bug here pertains to the fact that it isn't flushing ("syncing") the last 30 seconds of cached data to the disk beforehand. A cold reboot without unmounting could potentially cause all kinds of other data inconsistency problems to pop up.
/etc/rc.d/init.d/mountfs (or whatever it's called on your system) script right before the "umount" line.
The temporary fix seems to be to run sync manually. Stick "sync" in your
Liberty in your lifetime
Um, maybe because regular non-developer type people don't run out and grab the latest kernel that just came out and compile it themselve for the hell of it. Instead, they run whatever version comes with their distro.
/.
Anyone running the latest bleeding edge stuff keeps up with the LKML anyway, and KNOWS what is going on, way before it would hit a news site like
The sky is falling! Sheesh...
"While the kernel which has fs corruption bug is supposed to be used by non-production, testing environment, and for those you like to use bleeding edge release."
Bzzt. 2.4 is the current stable Linux branch, and 2.4.20 is the latest stable version of that branch.
While this kind of thing is not uncommon in the development branch, it's awful to see in a point release of the stable branch.