Slashdot Mirror
EXT4 Data Corruption Bug Hits Linux Kernel
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."
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.
I want to delete my account but Slashdot doesn't allow it.
I know he'd never do anything to harm me or my data.
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.
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!
Ezekiel 23:20
...and too deep. It awoke a being of segfaults and kernel panics.
So clearly the answer is General Tso's FS. Delicious, but you'll lose your data an hour later.
grammar nazi's
grammar Nazis
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!
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
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
Bisecting is also a way of killing bugs - or perhaps Bisecting is when you act like an insect that goes both ways.
it is only after a long journey that you know the strength of the horse.
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?]
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.