Re: [PATCH v6 22/31] ext4: submit and wait for pending disksize-grow I/O on writeback
From: Zhang Yi
Date: Thu Oct 08 2026 - 04:54:33 EST
On 10/5/2026 5:00 PM, Ojaswin Mujoo wrote:
On Thu, Sep 03, 2026 at 08:35:34PM +0800, Zhang Yi wrote:
From: Zhang Yi <yi.zhang@xxxxxxxxxx>Hi Zhang,
When the current writeback pass begins beyond the disksize-grow-pending
zeroed EOF block, the ioend worker would otherwise have to wait for the
pending EOF block to complete before it can advance i_disksize.
Otherwise the old EOF block could be exposed as stale data once
i_disksize advances past it.
Therefore, introduce the ioend mechanism for the pending range, tag
ioends that cover the pending zeroed EOF block which straddles
i_disksize with EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO in
ext4_iomap_writeback_submit(), and clear the bit and wake up all waiters
in ext4_iomap_end_bio() when such an ioend completes.
Clearing EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO does not depend on whether
the disksize grow I/O succeeds. That is, even if the I/O fails, we still
allow subsequent writes in the range to update i_disksize. This is
consistent with the previous behavior, and we rely on data_err=abort to
prevent metadata updates when data write failures occur.
In order to avoid the ioend that passes the pending range waiting for a
long time, proactively submit the pending range first in
ext4_iomap_writepages() so it completes in parallel with the rest of the
writeback.
Note that the handling of discarding the zeroed EOF folio will be
processed later, otherwise the bit will be set forever.
EXT4_STATE_DISKSIZE_GROW_PENDING will be set after everthing is done.
Signed-off-by: Zhang Yi <yi.zhang@xxxxxxxxxx>
---
fs/ext4/ext4.h | 6 ++++++
fs/ext4/inode.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++-
fs/ext4/page-io.c | 40 +++++++++++++++++++++++++++++++++++
3 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 1c3d736fb700..089dbd39c5c2 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3986,6 +3986,12 @@ extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
__u64 len, __u64 *moved_len);
/* page-io.c */
+/*
+ * The I/O range covers the zeroed EOF block that straddles i_disksize
+ * and will advance it upon completion.
+ */
+#define EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO 1UL
+
extern int __init ext4_init_pageio(void);
extern void ext4_exit_pageio(void);
extern ext4_io_end_t *ext4_init_io_end(struct inode *inode, gfp_t flags);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 05dd4ee805fb..4239be5a769f 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4366,7 +4366,10 @@ static int ext4_iomap_writeback_submit(struct iomap_writepage_ctx *wpc,
int error)
{
struct iomap_ioend *ioend = wpc->wb_ctx;
- struct ext4_inode_info *ei = EXT4_I(ioend->io_inode);
+ struct inode *inode = ioend->io_inode;
+ struct ext4_inode_info *ei = EXT4_I(inode);
+ unsigned int blocksize = i_blocksize(inode);
+ loff_t pstart, plen;
/*
* After I/O completion, a worker needs to be scheduled when:
@@ -4379,6 +4382,21 @@ static int ext4_iomap_writeback_submit(struct iomap_writepage_ctx *wpc,
test_opt(ioend->io_inode->i_sb, DATA_ERR_ABORT))
ioend->io_bio.bi_end_io = ext4_iomap_end_bio;
+ /*
+ * Mark the I/O as DISKSIZE_GROW_IO by setting io_private to
+ * EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO if it covers the pending range.
+ * Such I/O will allow or trigger i_disksize advancement in the
+ * ioend worker.
+ */
+ plen = ext4_iomap_get_disksize_pending_range(inode, &pstart);
+ if (plen &&
+ round_down(ioend->io_offset, blocksize) <= pstart &&
+ round_up(ioend->io_offset + ioend->io_size, blocksize) >=
+ pstart + plen) {
+ ioend->io_bio.bi_end_io = ext4_iomap_end_bio;
+ ioend->io_private = (void *)EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO;
+ }
+
/*
* ext4_iomap_end_bio() always defers endio processing, disable
* generic BIO in task to avoid double deferral since we will use
@@ -4398,6 +4416,33 @@ static const struct iomap_writeback_ops ext4_writeback_ops = {
.writeback_submit = ext4_iomap_writeback_submit,
};
+/*
+ * If the current writeback range begins after the pending zeroed EOF
+ * block range which straddles i_disksize, issue a separate writeback to
+ * flush it first, so as to avoid prolonged waiting.
+ */
+static void ext4_iomap_wb_submit_zeroed_eof(struct inode *inode,
+ struct writeback_control *wbc)
+{
+ struct address_space *mapping = inode->i_mapping;
+ loff_t pstart, plen, range_start;
+
+ if (wbc->range_cyclic)
+ range_start = (loff_t)mapping->writeback_index << PAGE_SHIFT;
+ else
+ range_start = wbc->range_start;
+
+ plen = ext4_iomap_get_disksize_pending_range(inode, &pstart);
+ if (!plen || range_start < pstart + plen)
+ return;
Maybe we can check here if pstart lies withing the same folio as the
writeback range, then we don't need an explicit flush as we will anyways
flush out the whole folio. We can check against the
mapping_min_folio_nrbytes perhaps.
Hi Ojaswin,
Thank you for the suggestion. IIUC, do you mean to change it somewhat
like the following:
if (!plen ||
round_down(range_start, mapping_min_folio_nrbytes(mapping)) <
pstart + plen)
return;
The benefit is that it covers the case of blocksize < PAGE_SIZE, where
the pending range occupies only part of the folio and range_start lands
in the middle or later part of that same folio. It does not help when
the pending range happens to be in a large folio, though, because
mapping_min_folio_nrbytes() is only a lower bound on the folio size.
That said, the pending range is the old EOF of the file and it is
unaligned, so that folio can more likely to be a single page than a
large one.
Or do you want it to be very precise, able to know exactly the size of
the folio containing the pending range and its positional relationship
with the writeback range? If the latter, that would require an exact
folio lookup, which seems a bit expensive and perhaps over-optimization
to me.
Thanks,
Yi.