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

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

[Andreas Dilger]

On Oct 12, 2026, at 12:53, Theodore Tso <tytso@mit.edu> wrote:
> 
> 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.)

Ted, do you recall if data=journal is used for the SMR patches that were
presented at FAST several years ago?  I've been thinking about reviving
them to help address the looming SMR drive armageddon that is coming.  My
recollection is that this patch used a large (data=?)journal to hold small
and unaligned writes until they could be aggregated, while large/aggregated
data writes go directly to a zone.

Metadata would basically live in the journal until checkpointed, and the
buffers for the metadata blocks could be dropped from RAM to allow huge
journals (either on a CMR HDD or NVMe today).  Checkpointing the journal
would either flush the blocks to an HDD linearly (with updates for the
block allocation in the inode/bitmap being journaled), and metadata being
"cleaned up" could just be re-journaled to the head of the journal (maybe
never actually being written into the filesystem).

The main other thing that would be needed is for mballoc to add a mode to
allocate blocks contiguously inside each zone.

Cheers, Andreas

>> 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
> 


Cheers, Andreas

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

[Korber, Markus]

On Mon, Oct 12, 2026, Theodore Tso wrote:
> 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.

I'd like to add another data point in support of Gabriele's use case.

We also use ext4 data=journal on embedded systems where unexpected
power loss is possible. Our main concern is not losing the most recent
few seconds of data. That is acceptable for our use case. What we want
to avoid is corruption of file contents after an unexpected power loss.

We performed repeated hard power-cut tests using both data=ordered and
data=journal. With data=ordered we observed, among other expected
failure modes, files containing NULs and partially written files where
the unwritten part contained NULs. These failure modes are particularly
difficult for applications to recover from.

With data=journal we still observed lost recent files, zero-length
files and truncated current writes, but we did not observe those
NUL-filled corruption patterns.

So at least for our use case, the useful property of data=journal is
not primarily reducing the amount of recent data that can be lost.
It is the different failure behavior when power is removed during file
I/O.

Regards,
Markus

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

[Zhang Yi]

On 10/19/2026 4:51 PM, Korber, Markus wrote:
> On Mon, Oct 12, 2026, Theodore Tso wrote:
>> 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.
> 
> I'd like to add another data point in support of Gabriele's use case.
> 
> We also use ext4 data=journal on embedded systems where unexpected
> power loss is possible. Our main concern is not losing the most recent
> few seconds of data. That is acceptable for our use case. What we want
> to avoid is corruption of file contents after an unexpected power loss.
> 
> We performed repeated hard power-cut tests using both data=ordered and
> data=journal. With data=ordered we observed, among other expected
> failure modes, files containing NULs and partially written files where
> the unwritten part contained NULs. These failure modes are particularly
> difficult for applications to recover from.
> 

If you're only doing regular append writes rather than post-EOF append
writes, then the upcoming buffered_iomap mount option should be able to
address this one (though in the short term it won't support all the
features of the buffered_head flow — hopefully it will be useful for
you), since the on-disk file size update is performed after the I/O
completes.

Regards,
Yi.

> With data=journal we still observed lost recent files, zero-length
> files and truncated current writes, but we did not observe those
> NUL-filled corruption patterns.
> 
> So at least for our use case, the useful property of data=journal is
> not primarily reducing the amount of recent data that can be lost.
> It is the different failure behavior when power is removed during file
> I/O.
> 
> Regards,
> Markus

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

[Andreas Dilger]

On Oct 19, 2026, at 02:51, Korber, Markus <markus.korber@anton-paar.com> wrote:
> 
> On Mon, Oct 12, 2026, Theodore Tso wrote:
>> 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.
> 
> I'd like to add another data point in support of Gabriele's use case.
> 
> We also use ext4 data=journal on embedded systems where unexpected
> power loss is possible. Our main concern is not losing the most recent
> few seconds of data. That is acceptable for our use case. What we want
> to avoid is corruption of file contents after an unexpected power loss.
> 
> We performed repeated hard power-cut tests using both data=ordered and
> data=journal. With data=ordered we observed, among other expected
> failure modes, files containing NULs and partially written files where
> the unwritten part contained NULs. These failure modes are particularly
> difficult for applications to recover from.
> 
> With data=journal we still observed lost recent files, zero-length
> files and truncated current writes, but we did not observe those
> NUL-filled corruption patterns.
> 
> So at least for our use case, the useful property of data=journal is
> not primarily reducing the amount of recent data that can be lost.
> It is the different failure behavior when power is removed during file
> I/O.

Hi Markus,
are you running with delalloc disabled when testing ordered mode?  That might be the source of NULs in recently written files.

Cheers, Andreas

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

[Korber, Markus]

On Oct 19, 2026, Andreas Dilger wrote:

> are you running with delalloc disabled when testing ordered mode?
> That might be the source of NULs in recently written files.

No, we did not explicitly disable delayed allocation.

The data=ordered tests were run with:

    data=ordered,commit=2,noatime,errors=continue

so delayed allocation should have been enabled with the normal ext4
default.

Markus

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

[Andreas Dilger]

On Oct 19, 2026, at 22:18, Korber, Markus <markus.korber@anton-paar.com> wrote:
> 
> On Oct 19, 2026, Andreas Dilger wrote:
> 
>> are you running with delalloc disabled when testing ordered mode?
>> That might be the source of NULs in recently written files.
> 
> No, we did not explicitly disable delayed allocation.
> 
> The data=ordered tests were run with:
> 
>   data=ordered,commit=2,noatime,errors=continue
> 
> so delayed allocation should have been enabled with the normal ext4
> default.

What I mean is that if you *do* disable delalloc then this might stop
the appearance of NULs at the end of a file after a crash.  The normal
"ordered" mode writes should sync data to the filesystem before the
size is updated in the inode, but delalloc does not do that.

Cheers, Andreas

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

[Zhang Yi]

On 10/23/2026 7:22 AM, Andreas Dilger wrote:
> On Oct 19, 2026, at 22:18, Korber, Markus <markus.korber@anton-paar.com> wrote:
>>
>> On Oct 19, 2026, Andreas Dilger wrote:
>>
>>> are you running with delalloc disabled when testing ordered mode?
>>> That might be the source of NULs in recently written files.
>>
>> No, we did not explicitly disable delayed allocation.
>>
>> The data=ordered tests were run with:
>>
>>    data=ordered,commit=2,noatime,errors=continue
>>
>> so delayed allocation should have been enabled with the normal ext4
>> default.
> 
> What I mean is that if you *do* disable delalloc then this might stop
> the appearance of NULs at the end of a file after a crash.  The normal
> "ordered" mode writes should sync data to the filesystem before the
> size is updated in the inode, but delalloc does not do that.
> 
> Cheers, Andreas

I think this is caused by the default dioread_nolock behavior. Once
dioread_nolock is enabled, the extents allocated during writeback
are unwritten, so ordered mode doesn't take effect, and the
transaction that updates i_disksize may hit the disk before the
data I/O is persisted.

Cheers,
Yi.

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