From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>, linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
yi.zhang@huawei.com, libaokun1@huawei.com, yukuai3@huawei.com,
yangerkun@huawei.com
Subject: Re: [PATCH 0/2] ext4: fix an data corruption issue in nojournal mode
Date: Thu, 2 Oct 2025 19:42:34 +0800 [thread overview]
Message-ID: <4a152e1b-c468-4fbf-ac0b-dbb76fa1e2ac@linux.alibaba.com> (raw)
In-Reply-To: <20250916093337.3161016-1-yi.zhang@huaweicloud.com>
Hi Ted,
On 2025/9/16 17:33, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
>
> Hello!
>
> This series fixes an data corruption issue reported by Gao Xiang in
> nojournal mode. The problem is happened after a metadata block is freed,
> it can be immediately reallocated as a data block. However, the metadata
> on this block may still be in the process of being written back, which
> means the new data in this block could potentially be overwritten by the
> stale metadata and trigger a data corruption issue. Please see below
> discussion with Jan for more details:
>
> https://lore.kernel.org/linux-ext4/a9417096-9549-4441-9878-b1955b899b4e@huaweicloud.com/
>
> Patch 1 strengthens the same case in ordered journal mode, theoretically
> preventing the occurrence of stale data issues.
> Patch 2 fix this issue in nojournal mode.
It seems this series is not applied, is it ignored?
When ext4 nojournal mode is used, it is actually a very
serious bug since data corruption can happen very easily
in specific conditions (we actually have a specific
environment which can reproduce the issue very quickly)
Also it seems AWS folks reported this issue years ago
(2021), the phenomenon was almost the same, but the issue
still exists until now:
https://lore.kernel.org/linux-ext4/20211108173520.xp6xphodfhcen2sy@u87e72aa3c6c25c.ant.amazon.com/
Some of our internal businesses actually rely on EXT4
no_journal mode and when they upgrade the kernel from
4.19 to 5.10, they actually read corrupted data after
page cache memory is reclaimed (actually the on-disk
data was corrupted even earlier).
So personally I wonder what's the current status of
EXT4 no_journal mode since this issue has been existing
for more than 5 years but some people may need
an extent-enabled ext2 so they selected this mode.
We already released an announcement to advise customers
not using no_journal mode because it seems lack of
enough maintainence (yet many end users are interested
in this mode):
https://www.alibabacloud.com/help/en/alinux/support/data-corruption-risk-and-solution-in-ext4-nojounral-mode
Thanks,
Gao Xiang
>
> Regards,
> Yi.
>
> Zhang Yi (2):
> jbd2: ensure that all ongoing I/O complete before freeing blocks
> ext4: wait for ongoing I/O to complete before freeing blocks
>
> fs/ext4/ext4_jbd2.c | 11 +++++++++--
> fs/jbd2/transaction.c | 13 +++++++++----
> 2 files changed, 18 insertions(+), 6 deletions(-)
>
next prev parent reply other threads:[~2025-10-02 11:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 9:33 [PATCH 0/2] ext4: fix an data corruption issue in nojournal mode Zhang Yi
2025-09-16 9:33 ` [PATCH 1/2] jbd2: ensure that all ongoing I/O complete before freeing blocks Zhang Yi
2025-09-16 10:56 ` Jan Kara
2025-09-16 9:33 ` [PATCH 2/2] ext4: wait for ongoing I/O to " Zhang Yi
2025-09-16 10:57 ` Jan Kara
2025-10-02 11:42 ` Gao Xiang [this message]
2025-10-06 13:52 ` [PATCH 0/2] ext4: fix an data corruption issue in nojournal mode Jan Kara
2025-10-06 14:37 ` Gao Xiang
2025-10-09 14:58 ` Theodore Ts'o
2025-10-15 2:44 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a152e1b-c468-4fbf-ac0b-dbb76fa1e2ac@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).