EXT4 deprecates its data=journal mode and plans to remove it in early 2028
On October 8, 2026, the Linux 7.3 Git merge deprecated EXT4’s data=journal mode, which writes file data and metadata to the journal before committing them, with removal scheduled for early 2028. Check your mount options in /etc/fstab: if you don’t enable data=journal explicitly, this deprecation does not affect you.
October 8, 2026. Michael Larabel reports on Phoronix that the EXT4 filesystem has deprecated its journaled mode, the data=journal mount option. Early 2028. That is the announced deadline for the mode’s final removal, after the 2027 LTS kernel. Linux 7.3. That is the release carrying the deprecation, via today’s Git merge. Why it matters: data=journal is EXT4’s safest option against data loss after a power failure, and anyone using it explicitly now has three years to migrate.
What data=journal does
To understand the deprecation, start with the role of the journal in a filesystem. EXT4 keeps a journal that records operations before they are applied to the main filesystem. On a crash or power loss, the journal is replayed at the next mount to repair an inconsistent state.
The data=journal mode pushes this logic to its maximum. With this option, all file data — not just metadata — is written to the journal before being committed to the main filesystem. Every data write therefore passes through the journal, then on to its final destination.
It is EXT4’s safest mode for data integrity. A power cut at the wrong moment leaves less room for corruption, because the data is in the journal before it is moved. For workloads where no loss is tolerable, that is a valuable guarantee.
The default mode, by contrast, is data=ordered. It journals only metadata, and orders writes so that data hits the disk before the metadata referencing it. It is a compromise that protects the filesystem structure without paying the cost of writing data twice.
The price: double writes and disabled features
The guarantee of data=journal is expensive, and that cost is exactly what condemns it.
The first price is write performance. Every piece of data is written twice — once to the journal, once to the filesystem. Phoronix describes a significant hit to write performance compared with data=ordered or data=writeback. On a server or a database, that overhead translates directly into latency and lost throughput.
The second price is subtler: data=journal disables two major EXT4 optimizations. It turns off delayed allocation, which batches writes to reduce fragmentation and improve throughput. It also disables Direct I/O, which lets applications — databases above all — bypass the kernel cache.
The result is a punishing combination. data=journal slows ordinary writes through double-writes, and it disables the very mechanisms that could compensate. It is a mode built for maximum safety at the cost of a machine that writes slowly.
Because of that cost, data=journal has long been a niche choice, reserved for workloads where a lost write is unacceptable and the write penalty is tolerated. Most systems never touch it, which is exactly why its code path sees so little real-world exercise.
Why now: fewer code paths to maintain
The deprecation is not driven by a vulnerability but by maintenance. The data=journal mode takes a distinct code path through EXT4, with its own journaled-write handling and its own interaction with allocation and Direct I/O — and it is rarely used.
A rarely exercised code path is a risk in itself. It receives less testing and less feedback, and every refactor of the rest of the filesystem has to accommodate it. Removing it simplifies the kernel and shrinks the surface to maintain. The trajectory is a classic one in the Linux kernel: deprecate first, remove later, after giving users time to migrate.
The schedule is explicit: deprecation in Linux 7.3, removal in early 2028, after the 2027 LTS kernel. Anchoring the removal after an LTS is a deliberate precaution: anyone who pins their kernel to an LTS is guaranteed the mode remains available on that branch, even after it disappears from newer releases.
The deprecation also reflects EXT4’s standing. It is the default filesystem on most major distributions, which is precisely why its maintenance matters so much: every optional code path carries a cost paid across millions of machines, and trimming a rarely used mode keeps the most widely deployed filesystem lean and ultimately more reliable.
What to check in your fstab
The practical question comes down to one command. The journaling mode is set at mount time, so it lives in /etc/fstab or in the output of mount.
# Look for a data=journal option on EXT4 mounts
grep -E 'ext4' /etc/fstab | grep -o 'data=[a-z]*'
# Or inspect the active mount
findmnt -t ext4 -o TARGET,OPTIONSThe diagnosis is binary. If no line mentions data=journal, you are running the default data=ordered (or an explicit data=writeback) and the deprecation does not affect you. If a line carries data=journal, you have three years to change.
For systems that do carry the flag, the fix is a one-line edit and a remount — no data migration and no reformatting. Removing the option from /etc/fstab and remounting returns the filesystem to the default data=ordered immediately.
The migration is simple in the vast majority of cases: remove the option and let the default data=ordered take over. For workloads that demanded data=journal’s maximum guarantee, the real answer lies elsewhere — an application that cannot tolerate any loss must rely on fsync() at the right moment, not on a mount mode that doubles every write. data=ordered already protects the integrity of the filesystem structure; it does not, by itself, protect the durability of an application transaction — but neither did data=journal without the corresponding fsync calls.
The real durability guarantee is fsync
Removing data=journal does not mean abandoning durability: it forces you to put it in the right place. The journaled mode gave an impression of safety — all data passed through the journal — but that safety was incomplete without the cooperation of the applications.
The reason lies in how the kernel and applications talk. An application that writes a file hands its data to the kernel cache; it is not immediately on disk. Only the fsync() call forces the actual write, and it is that call — not the mount mode — which guarantees a transaction’s durability.
Databases have known this forever. PostgreSQL, MySQL and SQLite issue fsync() when committing a transaction, precisely because it is the only portable way to guarantee a write survives a power cut. A data=journal mount without those fsync() calls protects a database no better than data=ordered with them.
The practical consequence is liberating. If a workload demands strong durability, the answer is in the application — fsync() calls placed correctly — not in a mount option that doubles every write, permanently. Migrating from data=journal to data=ordered is therefore also an occasion to verify that the critical applications are doing their part.
Verdict
If you have never written data=journal in a mount configuration, you have nothing to do: the default data=ordered mode is untouched, and this deprecation is a kernel simplification that is invisible to you. If you explicitly use data=journal for loss-sensitive workloads, use the three remaining years to migrate — drop the option in favor of the default, and move the durability guarantee to explicit fsync() calls in the application, which is the correct and portable method. In every case, do not confuse the deprecation of a mode with a deprecation of EXT4 itself: the filesystem remains the default on most distributions, and only one optional, slow and rare mode is taking its bow.