1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Talk Of "EXT5" File-System; Should EXT4 Be Frozen?

Linux Kernel

Published on 25 October 2012 03:23 PM EDT
Written by Michael Larabel in Linux Kernel
9 Comments

In the discussion that followed when it was found a nasty EXT4 file-system corruption bug hit recent Linux kernel stable releases, one user proposed that EXT4 be put in a feature-freeze mode and future work then be put towards an "EXT5" file-system, to which Ted Ts'o did respond.

In the Phoronix Forums discussion about the EXT4 corruption bug hitting the Linux 3.4/3.5/3.6 kernels, Ted Ts'o, the EXT4 file-system maintainer, ultimately jumped in on the discussion to respond to the numerous and polarized opinions of Phoronix readers.

One Phoronix reader suggested, "Maybe consider freezing all changes to Ext4 and make a new Ext5 for new ideas." Ted's response to this was:
We have considered this. Right now new features get added under experimental feature flags or mount options. One of the users who ran into problems were using experimental new features that are not enabled by default. We can't stop users from trying out new features that aren't enabled by default, just as we can't stop them from deciding to use ext5 instead of ext4 on production servers. Things like metadata checksums are not enabled by default specifically because they aren't ready yet. Brave users who try them out are invaluable, and I am grateful to people who help us do our testing, since that's the only way we can shake out the last bugs that aren't found in developer environments or via regression tests. But you make your choices, and take your chances when you turn on such experimental features.

And there are some real costs with forking the code base and creating a potential new "ext5". We already have had problems where bugs are fixed in ext4, and they aren't propagated to ext3. Just today I found a minor bug which was fixed in ext3, but not in ext2. And sometimes bugs are fixed in extN, but someone forgets to forward port the bug fix to extN+1. If we were to add an "ext5" it would make this problem much worse, since it would triple the potential ways that bug fixes might fail to get propagated to where they are needed.

Speaking of bug fixes, you can't freeze all changes, because we are still finding bugs. Heck, as part of deploying ext4 is deployed on thousands and thousands of thousands of machines in Google data centers, we found a bug that only showed up because we had deployed ext4 in great numbers. When we found the bug fix, I checked and found that the exact same bug existed in ext3, where it had not been found despite ten years of testing in enterprise linux releases, by companies such as IBM and Red Hat. (It had probably triggered a couple of times, but it was so rare that testers probably chalked it up to random hardware failure or cosmic rays; it was only because I was correlating failure reports --- and most were caused by hardware failures, not by software bugs --- across a very large number of machines that I could discern the pattern and find this particular bug.)

The problem is that sometimes bug fixes introduce other bugs. In this particular case, it was a bug fix which as backported to a stable kernel which apparently made this failure mode happen more often. If you really mean "freeze all changes", as opposed to just being full of snark, then that would also mean not taking any bug fixes. And if you want to stay on an older version of Linux, feel free..... that's what people who are using RHEL 5, or RHEL 4, or even in some cases RHAS 2.1 have chosen.
It's probably unlikely that we will see any EXT5 file-system for Linux anytime soon. Ted has also made some other file-system comments in this forum thread.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  2. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  3. AMD Radeon R9 285 Tonga Performance On Linux
  4. Apotop Wi-Copy
Latest Linux Articles
  1. AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver
  2. MSI: Update Your BIOS From The Linux Desktop
  3. NVIDIA vs. AMD 2D Linux Drivers: Catalyst Is Getting Quite Good At 2D
  4. 15-Way GPU Comparison With Mesa 10.3 + Linux 3.17
Latest Linux News
  1. Linux 3.18-rc1 Released One Week Early With Many Changes
  2. The VC4 Gallium3D Driver Is Still Moving Along For The Raspberry Pi
  3. Direct3D 9 Support Might Land Within Mainline Mesa 3D Drivers
  4. OpenGL Preview Benchmarks For NVIDIA's GeForce GTX 970
  5. HOPE: The Ease Of Python With The Speed Of C++
  6. Vitesse: Using LLVM To Speed Up Databases
  7. AMD Is Restructuring Again, Losing 7% Of Employees
  8. Linux Testing Of The NVIDIA GeForce GTX 970
  9. Qt 5.4 Now In Beta With Web, Bluetooth LE, Graphics Improvements
  10. AMD's Radeon R9 285 On Linux Offers Good OpenCL Performance
Latest Forum Discussions
  1. NVIDIA Presents Its Driver Plans To Support Mir/Wayland & KMS On Linux
  2. AMD Is Restructuring Again, Losing 7% Of Employees
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. Open-Source AMD Fusion E-350 Support Takes A Dive
  5. Upgrade to Kaveri, very slow VDPAU performance
  6. ChromeOS Drops Support For EXT2/EXT3/EXT4 File-Systems
  7. Lennart Poettering On The Open-Source Community: A Sick Place To Be In
  8. The Slides Announcing The New "AMDGPU" Kernel Driver