[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <176962347638.1138505.18169489887205179764.b4-ty@mit.edu>
Date: Wed, 28 Jan 2026 13:05:09 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: linux-ext4@...r.kernel.org, Zhang Yi <yi.zhang@...weicloud.com>
Cc: "Theodore Ts'o" <tytso@....edu>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, adilger.kernel@...ger.ca, jack@...e.cz,
ojaswin@...ux.ibm.com, ritesh.list@...il.com, yi.zhang@...wei.com,
yizhang089@...il.com, libaokun1@...wei.com, yangerkun@...wei.com,
yukuai@...-78bjiv52429oh8qptp.cn-shenzhen.alb.aliyuncs.com
Subject: Re: [PATCH v2] ext4: don't order data when zeroing unwritten or delayed block
On Tue, 23 Dec 2025 09:19:27 +0800, Zhang Yi wrote:
> When zeroing out a written partial block, it is necessary to order the
> data to prevent exposing stale data on disk. However, if the buffer is
> unwritten or delayed, it is not allocated as written, so ordering the
> data is not required. This can prevent strange and unnecessary ordered
> writes when appending data across a region within a block.
>
> Assume we have a 2K unwritten file on a filesystem with 4K blocksize,
> and buffered write from 3K to 4K. Before this patch,
> __ext4_block_zero_page_range() would add the range [2k,3k) to the
> ordered range, and then the JBD2 commit process would write back this
> block. However, it does nothing since the block is not mapped as
> written, this folio will be redirtied and written back agian through the
> normal write back process.
>
> [...]
Applied, thanks!
[1/1] ext4: don't order data when zeroing unwritten or delayed block
commit: 154922b34da9770223d9883ac6976635a786b5ba
Best regards,
--
Theodore Ts'o <tytso@....edu>
Powered by blists - more mailing lists