Re: ext4 data=journal deprecation: long-standing industrial use case

Re: ext4 data=journal deprecation: long-standing industrial use case

[Theodore Tso]

On Mon, Oct 12, 2026 at 03:41:29PM -0500, Gabriele Moabiti wrote:
> 
> In these deployments, we have not experienced problems with this
> configuration over those 15 years. It has been a reliable solution for our
> operating conditions.
> I understand that data=journal is deprecated and scheduled for removal in
> January 2028. Given this established industrial use case, could the
> decision be reconsidered, perhaps retaining full data journaling as an
> optional feature?

The challenge with data=journal is that it adds a lot of complexity,
and more and more of the advanced featuers are simply "turned off" and
the original code path is used for data=journal --- and the "original
code path" is only used by the data=journal case.  This has the
following of undesireable outcomes:

   * Extra code paths == extra maintenance overhead
   * The data=journal specific codepaths are getting much less testing
   * There are known test failures with data=journal which are not
     getting addressed.  (n.b.  If paying customers were supporting with $$$
     the SWE investment of data=journal this could be better addressed, but
     at the moment data=journal is essentially best efforts by volunteers.)

> If removal goes ahead, will ext4 provide an alternative with equivalent
> protection against interrupted data writes and abrupt power loss? In
> particular, I would appreciate clarification on how users relying on full
> data journaling are expected to preserve comparable guarantees within ext4.

The phrase "comparable guarantees" is not particularly well defined, because...

> I understand that data=journal does not make application-level updates
> atomic or preserve data still buffered in userspace. Nevertheless, its
> protection beyond metadata-only journaling is valuable for our deployments.

Given that there is no guarantees of what writes will be persisted
with respect to program execution, it's unclear exactly what your
deployments are requiring or assuming.

That being said, I *suspect* that this should cover most, if not all
of your deployments' requirements.

echo 500 > /proc/sys/vm/dirty_expire_centisecs
echo 100 > /proc/sys/vm/dirty_writeback_centisecs

To make these changes persistent after a reboot, put the following in
/etc/sysctl.conf, or in a file in /etc/sysctl.d/

vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100

What these changes will do is if there are any dirty pages, writeback
will be initiated after 5 seconds (vm.dirty_expire_centisecs) and the
writeback flusher kernel threads will wake up once a second
(vm.dirty_writeback_centisecs).

The default values of these two settings are 30 seconds (3000) and 5
seconds (500), respectively.  By default, ext4 uses a commit time of 5
seconds (mount option commit=300).  In data=journal mode, when we
close an jbd2 journal commit, we effectively force data to be
persisted after a crash.  So by setting vm.dirty_expire_centisecs to
500, this will have roughly the same effect --- which is to say, after
a write first dirties a page, that page will be persisted after 5
seconds.

If the application wants a guarantee that a write is persisted, it
should use fsync(2).  But if you don't want to modify the application,
the window between when the application writes a file to when the data
is persisted can be reduced from 30 seconds to 5 seconds either by
using data=journal *or* setting dirty_expire_centisecs.

There will be some slight differences in behavior, but given that
data=journal doesn't have any real guarantees ---- if you want those
guarantees, using fsync(2) or fdatasync(2), hopefully it should be
good enough.  You may also find that performance may be improved by
using dirty_expire_centisecs if you are bottlenecked by the storage
device's I/O throughput limits, and it will also reduce flash write
endurance impacts (and hence improve SSD lifetime) if you are using
flash storage.

Can you give it a try and see if it works for you?

> We would prefer to continue using a normally writable ext4 filesystem,
> without introducing an overlay or migrating to another filesystem.

Note that no other file system has anything like data=journal, so
introducing an overlay (not sure what you mean by that) or migrating
to another file system is not likely to help you.

Cheers,

   	   	       	      	     	     - Ted

ext4 data=journal deprecation: long-standing industrial use case

[Gabriele Moabiti]

Hello,

I am writing regarding the proposed removal of data=journal:
https://lists.openwall.net/linux-ext4/2026/09/24/40

I develop and maintain a Linux distribution that has been used for
approximately 15 years on thousands of industrial PCs. These machines
may be powered off abruptly, without a clean shutdown.
We use ext4 with the following mount options:

rw,noatime,nodioread_nolock,nodelalloc,commit=1,data=journal

In these deployments, we have not experienced problems with this
configuration over those 15 years. It has been a reliable solution for
our operating conditions.
I understand that data=journal is deprecated and scheduled for removal
in January 2028. Given this established industrial use case, could the
decision be reconsidered, perhaps retaining full data journaling as an
optional feature?
If removal goes ahead, will ext4 provide an alternative with
equivalent protection against interrupted data writes and abrupt power
loss? In particular, I would appreciate clarification on how users
relying on full data journaling are expected to preserve comparable
guarantees within ext4.

I understand that data=journal does not make application-level updates
atomic or preserve data still buffered in userspace. Nevertheless, its
protection beyond metadata-only journaling is valuable for our
deployments.
We would prefer to continue using a normally writable ext4 filesystem,
without introducing an overlay or migrating to another filesystem. I
compile our kernels myself.
Thank you for considering this use case and for your work on ext4.

Gabriele Moabiti