From: yizhang089@gmail.com
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, adilger.kernel@dilger.ca,
libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com,
ritesh.list@gmail.com, yi.zhang@huawei.com,
yi.zhang@huaweicloud.com, yizhang089@gmail.com,
chengzhihao1@huawei.com, yangerkun@huawei.com
Subject: [PATCH 0/6] ext4: fix unaligned edge handling in FALLOC_FL_WRITE_ZEROES
Date: Wed, 1 Jul 2026 22:20:03 +0800 [thread overview]
Message-ID: <20260701142009.1510104-1-yizhang089@gmail.com> (raw)
From: Zhang Yi <yi.zhang@huawei.com>
Hi,
The current FALLOC_FL_WRITE_ZEROES implementation in ext4 does not
correctly handle unaligned edge blocks. FALLOC_FL_WRITE_ZEROES is
needed to convert the requested range to written extents with zeroed
content, but the existing code only partially zero the edges and never
guarantees that:
1) edges that are clean unwritten extents or holes get promoted to
written extents, and
2) edges that are dirty unwritten or delalloc get their underlying
extents converted to written before the syscall returns.
Both cases leave the on-disk extent type unwritten, violating the
WRITE_ZEROES contract, and in these cases a subsequent sync buffered
overwrite would still observe pending metadata changes from the
conversion work that should have been completed by WRITE_ZEROES itself.
This series fixes the unaligned edge handling and cleans up a related
redundant i_disksize update. The first three patches are preparatory:
moving ext4_zero_partial_blocks() earlier in ext4_zero_range(),
documenting the return semantics of ext4_load_tail_bh(), and
replacing the single bool output of ext4_zero_partial_blocks() with a
per-edge bitmask (EXT4_PARTIAL_ZERO_START/END). The next two patches
fix the two scenarios above by expanding the aligned allocation range
outward for skipped (clean unwritten or hole) edges, and by writing
back partial-zeroed edges so the underlying extents are converted to
written. The final patch drops the now-redundant
ext4_update_disksize_before_punch() call on the WRITE_ZEROES path,
since WRITE_ZEROES is mutually exclusive with KEEP_SIZE and the
i_disksize update is already handled by ext4_alloc_file_blocks().
Thanks,
Yi.
Discussion Link:
https://lore.kernel.org/linux-xfs/0b7f1a4f-da1c-4297-8099-98d738070ab7@huaweicloud.com/
Zhang Yi (6):
ext4: move partial block zeroing earlier in ext4_zero_range()
ext4: clarify return semantics of ext4_load_tail_bh()
ext4: track partial-zero outcome per edge in
ext4_zero_partial_blocks()
ext4: zero out whole block for clean edges in WRITE_ZEROES
ext4: write back partial-zeroed edges in WRITE_ZEROES
ext4: skip ext4_update_disksize_before_punch() in WRITE_ZEROES
fs/ext4/ext4.h | 5 ++++-
fs/ext4/extents.c | 47 +++++++++++++++++++++++++++++++++++++----------
fs/ext4/inode.c | 42 +++++++++++++++++++++++++++++++++++-------
3 files changed, 76 insertions(+), 18 deletions(-)
--
2.53.0
next reply other threads:[~2026-07-01 14:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 14:20 yizhang089 [this message]
2026-07-01 14:20 ` [PATCH 1/6] ext4: move partial block zeroing earlier in ext4_zero_range() yizhang089
2026-07-02 9:40 ` Jan Kara
2026-07-01 14:20 ` [PATCH 2/6] ext4: clarify return semantics of ext4_load_tail_bh() yizhang089
2026-07-02 9:53 ` Jan Kara
2026-07-02 14:40 ` Zhang Yi
2026-07-02 16:43 ` Jan Kara
2026-07-03 3:39 ` Zhang Yi
2026-07-03 16:01 ` Jan Kara
2026-07-04 1:32 ` Zhang Yi
2026-07-01 14:20 ` [PATCH 3/6] ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks() yizhang089
2026-07-02 9:57 ` Jan Kara
2026-07-01 14:20 ` [PATCH 4/6] ext4: zero out whole block for clean edges in WRITE_ZEROES yizhang089
2026-07-01 14:20 ` [PATCH 5/6] ext4: write back partial-zeroed " yizhang089
2026-07-02 10:05 ` Jan Kara
2026-07-01 14:20 ` [PATCH 6/6] ext4: skip ext4_update_disksize_before_punch() " yizhang089
2026-07-02 10:19 ` Jan Kara
2026-07-02 14:51 ` Zhang Yi
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=20260701142009.1510104-1-yizhang089@gmail.com \
--to=yizhang089@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=chengzhihao1@huawei.com \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.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