Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Serious EXT4 Data Corruption Bug Hits Linux Kernel

Anonymous Coward writes | about 2 years ago

Linux 1

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."
Link to Original Source

cancel ×

1 comment

Sorry! There are no comments related to the filter you selected.

XFS (1)

bluefoxlucid (723572) | about 2 years ago | (#41753133)

It's really between EXT and XFS at this point.

BTRFS is too new (keeps getting new features, has some drawbacks, and FSCK doesn't work) and specifically for SSD and other random-optimized media. BTRFS assumes reading from random areas is fast, and so writes linear meta-data because it's easy to find the meta-data and no seek time is incurred reading it; whereas searching and allocating and optimizing and packing is intensive and slow--better for spinning disks, but a lot of work for no benefit on SSD.

Reiser* has always been terrible--it was the first really recognized journaling and tail-packing filesystem, but even with Reiser4 the whole xattr thing is a no-go, so no SELinux and no Tracker and other xattr uses. Among other things, it's just not got a lot of driving force behind development.

JFS is ... not widely deployed in Linux.

ext3 isn't old. ext4 is new and is The New XFS. XFS has a long history of the same bugs that have been plaguing ext4, and ext4 has steadily fixed the same bugs in the same way. XFS still has a few feature-misses, and you don't want to drop power with XFS--it won't break the FS, but it has a bigger data loss window. Can't shrink XFS, it's complex and nobody has managed it safely yet. XFS journal has to be emptied before switching between 32/64 bit systems. XFS doesn't support journaling data, which means you can't use ordered data mode and use a fast, reliable external log device (an SSD) to greatly speed up writes.

XFS is a great file system, but know what you're getting. If you don't want to shrink and don't care about the semantics of a powerloss now or 15 seconds ago (or you have a UPS), XFS. Otherwise ext4, or ext3.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?