EXT4 Data Corruption Bug Hits Linux Kernel 249
An anonymous reader writes "An EXT4 file-system data corruption issue has reached the stable Linux kernel. The latest Linux 3.4, 3.5, 3.6 stable kernels have an EXT4 file-system bug described as an apparent serious progressive ext4 data corruption bug. Kernel developers have found and bisected the kernel issue but are still working on a proper fix for the stable Linux kernel. The EXT4 file-system can experience data loss if the file-system is remounted (or the system rebooted) too often."
Re:Bisected? (Score:5, Funny)
No this means the kernel has bug-like tendencies from time to time, but is not exclusively buggy. For instance when it's in college, or if its at a bar, and has had a few drinks, well then it might be buggy, but normally at work and at home and to all its friends it acts stable.
This is why I stick to Reiser (Score:5, Funny)
I know he'd never do anything to harm me or my data.
I don't see the problem then... (Score:5, Funny)
The EXT4 file-system can experience data loss if the file-system is remounted (or the system rebooted) too often.
We're talking about Linux users here...move along.
Really clever... (Score:5, Funny)
The EXT4 file-system can experience data loss if the file-system is remounted (or the system rebooted) too often."
They're trying to boost the average uptime of all installations by making people keep their machines turned on. It's just a continuation of the uptime war waged with the BSD folks!
Re:This is why I stick to Reiser (Score:2, Funny)
Or your wife?
The file system dug too greedily... (Score:3, Funny)
...and too deep. It awoke a being of segfaults and kernel panics.
Re:Reiserfs became 'murderfs'... (Score:5, Funny)
So clearly the answer is General Tso's FS. Delicious, but you'll lose your data an hour later.
Your Papers Please (Score:5, Funny)
grammar nazi's
grammar Nazis
Re:This is why I stick to Reiser (Score:2, Funny)
In other words... (Score:1, Funny)
This is what you get when you use a filesystem that wasn't developed by a real company.
Because if they had to worry about losing money, they would make damned sure that problem didn't exist. Or at least make it go away. I thought this "problem" existed with ext4 for years.
Yeah, Micro$oft is evil, but their FS works. And file corruption isn't a serious issue except when hard drives fail, and, well, in that case...DERP!
LOL (Score:0, Funny)
The EXT4 file-system can experience data loss if the file-system is remounted (or the system rebooted) too often."
"You're just rebooting it wrong."
-Loonix filesystem developer
Re:Bisected? (Score:4, Funny)
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
Nah, He only needs the latest SHA1 for each roll outcome commit as that'll point up the GIT tree :-D
Re:Bisected? (Score:2, Funny)
Bisecting is also a way of killing bugs - or perhaps Bisecting is when you act like an insect that goes both ways.
Re:Bisected? (Score:3, Funny)
Nah!
Your'e wrong!!
The 0's go to the top of the page, and the 1's to the bottom!!!
(As the 0's have air bubbles that make them float...)
[An irrelevant irrelevancy?]
Re:Well of course! (Score:4, Funny)
Lastly, my geek friends, mounting too often can cause burning friction which can destroy data and cause irritation and discomfort.
I never had a problem with frequent mounting, however I have now found a side effect from a mount I performed last year. A child-process was forked into existence shortly after the mount, and now we find we're continuously receiving interrupts from the process, which has affected pretty much every aspect of system administration.
I find that performing the mount is occasionally possible, but having to umount to give resources to deal with the child process (which often core dumps, and needs a lot of user interaction), before ejecting can lead to frustration and cold showers.
Most of the time my team is simply trying to run sleep whenever we can.