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
Forgive me for gloating, but I'm once again elated at how quickly this bug was squashed. Literally hours after the kernel was released, we have a fix available. Meanwhile, Windorks are still getting hammered by the Klez and ILOVEYOU virii. It's a miracle Linux and less popular open source programs like *BSD haven't wiped out the competition entirely.
Of course, I'm sure some of the more bleeding-edge types were bitten by this buglet, but I guess that comes with the territory; backup backup backup! I hope no Slashdotters lost any of their porn collections.
Karma: Good (despite my invention of the Karma: sig)
In 2.4.20-pre5 an optimisation was made to the ext3 fsync function
/* In writeback mode, we need to force out data buffers too. In /*
e read the FAQ at http://www.tux.org/lkml/
which can very easily cause file data corruption at unmount time. This
was first reported by Nick Piggin on November 29th (one day after 2.4.20 was
released, and three months after the bug was merged. Unfortunate timing)
This only affects filesystems which were mounted with the `data=journal'
option. Or files which are operating under `chattr -j'. So most people
are unaffected. The problem is not present in 2.5 kernels.
The symptoms are that any file data which was written within the thirty
seconds prior to the unmount may not make it to disk. A workaround is
to run `sync' before unmounting.
The optimisation was intended to avoid writing out and waiting on the
inode's buffers when the subsequent commit would do that anyway. This
optimisation was applied to both data=journal and data=ordered modes.
But it is only valid for data=ordered mode.
In data=journal mode the data is left dirty in memory and the unmount
will silently discard it.
The fix is to only apply the optimisation to inodes which are operating
under data=ordered.
--- linux-akpm/fs/ext3/fsync.c~ext3-fsync-fix Sat Nov 30 23:37:33 2002
+++ linux-akpm-akpm/fs/ext3/fsync.c Sat Nov 30 23:39:30 2002
@@ -63,10 +63,12 @@ int ext3_sync_file(struct file * file, s
*/
ret = fsync_inode_buffers(inode);
-
- * the other modes, ext3_force_commit takes care of forcing out
- * just the right data blocks. */
- if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)
+
+ * If the inode is under ordered-data writeback it is not necessary to
+ * sync its data buffers here - commit will do that, with potentially
+ * better IO merging
+ */
+ if (!ext3_should_order_data(inode))
ret |= fsync_inode_data_buffers(inode);
ext3_force_commit(inode->i_sb);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
-- Note: If you don't agree with me, don't bother replying. I won't read it.
In fact, there is a reply to that on LKM:
In fact it was reported on lkml on 18th July IIRC before 2.4.19 was
released if that is any help to you. 2.4.19 and 2.4.20 are affected
and I haven't tested previous releases. I was going to re-report it
sometime, but Alan brought it to light just the other day.
Nick
-- Note: If you don't agree with me, don't bother replying. I won't read it.
So, I'm clueless. But there's a lot of smart people on Slashdot. No, really, how often does one actually unmount a volume at home? In a production environment? When you shut down, is an unmount performed? If so, is the cached metadata and data flushed manually beforehand? Does this mean it's safer to simply reboot one's computer rather than carefully shut it down?
You like splinters in your crotch? -Jon Caldara
JUST DON'T SHUT YOUR SYSTEM OFF! MUWAHAHAHAHAA!!
just kiddin'
Fortunately, this bug didn't make it into 2.5 so it won't be propogated forward. Hint: the quick fix ISN'T a quick fix, it doesn't work.
Either stick with 2.4.19, don't use journaled file data, or sync before umounting (I do that anyway... just superstitious I guess ^_^).
It will take a few days to add some extra magic to the umount logic to flush all buffers in an intelligent way. Hopefully this optimization is worth the effort for dudes with high-uptime.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Really though, CERT advisories are inadequate tools for measuring vulnerability. Assuming Linux+apache+ssh, etc., all had equal number of bugs, the number of CERT advisories would be dramatically higher for Linux as opposed to Windows, since Microsoft forces people to hush up when a hole is found, and in the case of Linux, the bugs get reported several times, and the same hole in several distros likely becomes different bugs.
Hence, the article draws a similar conclusion to something like "Our army suffered more casualties than our opponent's army; hence, our opponent is the victor."
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Why didn't this make it to the front page? It would be prudent to warn the visitors who don't regularly check the developers section, so that they can take appropriate measures to avoid corruption. This is just plain irresponsible.
I think the answer here is simply to avoid any Linux kernels released close to Thanksgiving.
Tarsnap: Online backups for the truly paranoid
Let's have a close look at the costs involved when running a Linux system.
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
I just got a similar report of a bug from a Accounting software vendor alerting us to a bug in Windows.
Apparently in W2k SP1 MS broke something that caused data not to be writen from disk cache to the actual disk, which caused data corruption. This was only fixed in SP3.
I just find it interesting that this bug was not common knowledge as it is not really a "security" issue so they can't hide behind that smoke screen.
Ironically, yes. Since it only affects you when unmount a disk, and the only reason i unmounted a disk was to reboot the kernel after recompiling with the bug fix!
Oh well, it's not as if i have anything better to do than surf for porn. And my dick could use a rest from the constant masturbation.
Do you even lift?
These aren't the 'roids you're looking for.
BTW, if you use ext3 with the default mount options, you will not run into this problem. Its only if you override the mount default of data=ordered and use the data=journal option that the problem even occurs.
Hell, it took me several minutes of searching to even find out what the option was to even cause the problem. Something tells me this won't affect many people. Maybe someone who knows ext3 internals will enlighten us with why someone would want to use data=journal.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
can I get around this shyte by using alan cox's developmental tree?
I always wait several days now before I even start to experiment with a new kernel. Probably good practice anyway :-)