A series of critical bug fixes for the EXT4 file system landed in the Linux 7.0 release candidate cycle this week, underscoring persistent stability concerns in the most widely deployed file system in Linux history. The patches, pulled into Linux 7.0-rc6 by Linus Torvalds, address data corruption risks, journaling errors, and race conditions that have plagued EXT4 in recent kernel releases.
This isn’t a routine maintenance update. It’s a signal.
EXT4 has served as the default file system for most major Linux distributions for over 15 years. It underpins everything from enterprise servers running Red Hat Enterprise Linux to embedded devices, cloud instances on AWS and Google Cloud, and Android smartphones. When EXT4 has problems, the blast radius is enormous — even if most users never realize it. The fixes merged into rc6 suggest that some of these problems were serious enough to threaten data integrity, the single most important guarantee any file system must provide.
As Phoronix reported, the EXT4 fixes were among the most notable pull requests in the Linux 7.0-rc6 release. Ted Ts’o, the longtime EXT4 maintainer and one of the most respected kernel developers in the Linux community, submitted the patches. Torvalds merged them into the mainline tree, continuing the march toward a stable Linux 7.0 release expected in the coming weeks.
What Broke, and How Bad Was It?
The specific fixes address several categories of bugs. Some involve the journaling subsystem — the mechanism EXT4 uses to ensure that file system operations are atomic, meaning they either complete fully or not at all. Journaling is the reason you don’t lose your entire disk when the power goes out mid-write. Bugs here are the kind that keep storage engineers up at night.
Other patches target race conditions. These are timing-dependent bugs where two operations collide in ways the code didn’t anticipate. Race conditions are notoriously difficult to reproduce and diagnose. They tend to surface under heavy workloads — exactly the conditions found in production data centers and high-throughput computing environments. A race condition in a file system can lead to corrupted metadata, lost files, or kernel panics. None of those outcomes are acceptable.
There are also fixes for edge cases in extent handling. EXT4 uses extents — contiguous blocks of storage — to improve performance over the older block-mapping approach used by EXT3. But extent handling introduces complexity, and that complexity has been a recurring source of bugs. The patches in this cycle address scenarios where extent trees could become inconsistent, potentially leading to silent data corruption.
Silent data corruption. The two words no storage engineer ever wants to hear.
The EXT4 fixes weren’t the only notable changes in rc6. The release candidate also includes updates across various subsystems, as is typical for this stage of the kernel development cycle. But the file system patches stand out because of their implications for data safety. Torvalds has historically been vocal about the importance of regression-free releases, and file system bugs represent some of the highest-risk regressions possible.
The Linux kernel development process follows a structured cadence. After the merge window closes for a new version, a series of release candidates — rc1 through typically rc7 or rc8 — are issued over subsequent weeks. Each rc is supposed to contain only bug fixes, not new features. By rc6, the kernel should be approaching stability. The fact that significant EXT4 fixes are still arriving at this stage suggests either that these bugs were recently discovered or that they were complex enough to require extended development and review time. Both possibilities are concerning in their own way.
Ted Ts’o has maintained EXT4 for years with a conservative approach that prioritizes stability. His patches go through extensive review before submission. That this batch of fixes was substantial enough to warrant specific attention in the rc6 announcement speaks to the severity of the underlying issues.
EXT4’s Long Shadow — and the Alternatives Circling
The broader context matters here. EXT4 is aging. It was designed in an era when spinning hard drives were dominant, file systems measured in terabytes were large, and NVMe didn’t exist. It has been extended and patched repeatedly to handle modern workloads, but its fundamental architecture reflects decisions made nearly two decades ago.
Alternatives exist. Btrfs, once considered EXT4’s heir apparent, has gained adoption in SUSE Linux Enterprise and Fedora workstation editions. It offers features EXT4 lacks: snapshots, built-in RAID, checksumming, and online defragmentation. But Btrfs has had its own stability struggles, and many enterprise users remain wary. Facebook (now Meta) famously deployed Btrfs at scale, but that required significant in-house engineering effort.
XFS, maintained by Darrick Wong at Oracle, has become the default for Red Hat Enterprise Linux’s larger storage configurations. It handles large files and high-throughput workloads exceptionally well. And then there’s bcachefs, the newcomer merged into the Linux kernel in version 6.7, which promises modern file system features with a focus on reliability and performance. Its creator, Kent Overstreet, has been outspoken about what he sees as fundamental design limitations in older file systems.
But none of these alternatives have displaced EXT4 in practice. Not yet. The installed base is simply too large, the migration costs too high, and the institutional inertia too strong. Most Linux distributions still default to EXT4 for root partitions. Most cloud providers provision EXT4 volumes unless customers specify otherwise. Most Android devices run EXT4 or its close relative, F2FS.
So when EXT4 has bugs, the industry pays attention — or at least, it should.
The Linux 7.0 release itself marks a notable version number milestone. Torvalds has said repeatedly that major version numbers are arbitrary and don’t signify architectural changes. He bumped from 5.x to 6.0 simply because the minor version numbers were getting unwieldy, and the same logic applies to the jump to 7.0. Still, a .0 release carries symbolic weight, and shipping it with known file system data corruption bugs would be a bad look for the kernel community.
The kernel development community’s response to these EXT4 issues has been characteristically efficient. Patches were submitted, reviewed, tested, and merged within the normal rc cycle. There’s no indication that the Linux 7.0 release will be delayed because of these fixes. The process worked as designed.
But the frequency of EXT4 fixes in recent kernel cycles raises a longer-term question: how much longer can a file system designed in 2006 continue to be the backbone of modern Linux deployments? Each kernel release seems to bring another round of patches for edge cases, race conditions, and corner-case corruption scenarios. The code is mature, yes. But mature code in a file system context means code that has been patched so many times that the interaction between fixes itself becomes a source of risk.
For enterprise users running mission-critical workloads on EXT4, the takeaway is straightforward. Stay current with kernel updates. Test release candidates against your workloads before deploying to production. And start evaluating whether your storage requirements have outgrown what EXT4 was designed to handle.
For the kernel community, the EXT4 fixes in Linux 7.0-rc6 are a reminder that the most important code is often the least glamorous. Nobody writes conference talks about fixing a race condition in extent tree handling. But that’s the work that keeps billions of devices from losing data.
The final Linux 7.0 release is expected within the next two to three weeks, pending one or two more release candidates. When it ships, the EXT4 fixes will be there — invisible to most users, indispensable to all of them.
WebProNews is an iEntry Publication