From: Zhang Yi <yizhang089@gmail.com>
To: Jan Kara <jack@suse.cz>, Zhang Yi <yi.zhang@huaweicloud.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, libaokun@linux.alibaba.com,
ojaswin@linux.ibm.com, ritesh.list@gmail.com, djwong@kernel.org,
hch@infradead.org, yi.zhang@huawei.com, yangerkun@huawei.com,
yukuai@fnnas.com
Subject: Re: [PATCH v4 18/23] ext4: wait for ordered I/O in the iomap buffered I/O path
Date: Mon, 22 Jun 2026 11:32:16 +0800 [thread overview]
Message-ID: <9ab9281d-c5dc-4183-8bc9-b53b5a4ac9c0@gmail.com> (raw)
In-Reply-To: <k3w5c3cyg2py4kums7nhdwjg6b6pm43qtweepuolk57xtmnotz@yxkm2k6sqfc6>
On 6/18/2026 9:48 PM, Jan Kara wrote:
> On Mon 11-05-26 15:23:38, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@huawei.com>
>>
>> For append writes, wait for ordered I/O to complete before updating
>> i_disksize. This ensures that zeroed data is flushed to disk before the
>> metadata update, preventing stale data from being exposed during
>> unaligned post-EOF append writes.
>>
>> Suggested-by: Jan Kara <jack@suse.cz>
>> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
>
> Frankly, this all looks too complex to me. Plus your are adding 32-bytes to
> struct ext4_inode_info which isn't great either. Why don't you just do
> filemap_fdatawait() for the byte at old i_disksize and be done with it?
>
> I believe we have to simplify this. All this complexity (and thus
> maintenance burden) across several patches for the corner case of zeroing
> tail block on extention is in my opinion difficult to justify.
>
> Honza
Hi, Jan!
Thanks for the review. I understand the concern about complexity and the
32-byte increase to ext4_inode_info. I tried using
filemap_fdatawait_range() as you suggested, but found two issues where
this solution doesn't work.
1. ioend worker deadlock
Since worker concurrency resources are limited, we cannot wait for
another ioend worker to complete within one ioend worker with the same
work_struct. If the worker calls
filemap_fdatawait_range(byte_at_old_disksize) to wait for the zeroed
block's folio writeback to complete, it sleeps holding the only worker
slot. If the folio contains blocks requiring extent conversion, its
writeback bit is cleared by iomap_finish_ioends() running inside
another worker -- which can only run after the current worker finishes
its batch.
Concretely:
- Worker W1 processes ioend A, calls filemap_fdatawait_range() on
the old EOF byte, sleeps.
- The zeroed data is in ioend B. bio_endio defers it to
i_iomap_ioend_list and calls queue_work().
- queue_work() on i_iomap_ioend_work is idempotent: it returns false
because the work is currently executing (even though sleeping).
- ioend B sits in the list, never gets processed.
- The folio writeback bit is only cleared by processing ioend B.
- W1 sleeps forever -> deadlock.
Therefore, I think we have to put the wakeup logic in
ext4_iomap_end_bio() that runs in interrupt context without consuming
a worker thread. The ordered range tracking and wait queue are what
make that possible.
2. Truncate-up needs an accurate state query
In the follow-up patch 19, ext4_set_inode_size() must make a precise
decision when updating i_disksize during truncate up.
This needs a state query: "is there ordered zero I/O in flight right
now?" If yes, the i_disksize update is deferred to
ext4_iomap_wb_update_disksize(is_ordered=true), which advances
i_disksize to i_size when the ordered I/O completes. If no, we must
advance i_disksize immediately, otherwise we will lose the updating
forever.
Therefore, we need to track the state of the ordered range. Simply
using filemap_fdatawait_range() doesn't work. i_ordered_len serves as
a maintained state flag that both the ioend completion path and the
setattr path can read atomically without sleeping.
Suggestions?
Regarding the bloat of ext4_inode_info, perhaps we can drop the
wait_queue_head_t (24 bytes) and use wait_var_event()/ wake_up_var()
instead. Would this be acceptable?
Thanks,
Yi
>
>> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
>> index 078feda47e36..9ce2128eea3e 100644
>> --- a/fs/ext4/ext4.h
>> +++ b/fs/ext4/ext4.h
>> @@ -1195,6 +1195,15 @@ struct ext4_inode_info {
>> #ifdef CONFIG_FS_ENCRYPTION
>> struct fscrypt_inode_info *i_crypt_info;
>> #endif
>> +
>> + /*
>> + * Track ordered zeroed data during post-EOF append writes, fallocate,
>> + * and truncate-up operations. These parameters are used only in the
>> + * iomap buffered I/O path.
>> + */
>> + ext4_lblk_t i_ordered_lblk;
>> + ext4_lblk_t i_ordered_len;
>> + wait_queue_head_t i_ordered_wq;
>> };
>>
>> /*
>> @@ -3858,6 +3867,8 @@ extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
>> __u64 len, __u64 *moved_len);
>>
>> /* page-io.c */
>> +#define EXT4_IOMAP_IOEND_ORDER_IO 1UL /* This I/O is an ordered one */
>> +
>> 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 e013aeb03d7b..11fb369efeb1 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -4345,6 +4345,7 @@ static int ext4_iomap_writeback_submit(struct iomap_writepage_ctx *wpc,
>> {
>> struct iomap_ioend *ioend = wpc->wb_ctx;
>> struct ext4_inode_info *ei = EXT4_I(ioend->io_inode);
>> + ext4_lblk_t start, end, order_lblk, order_len;
>>
>> /*
>> * After I/O completion, a worker needs to be scheduled when:
>> @@ -4357,6 +4358,30 @@ 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 ordered. Ordered I/O requires separate endio
>> + * handling and must not be merged with regular I/O operations.
>> + */
>> + order_len = READ_ONCE(ei->i_ordered_len);
>> + if (order_len) {
>> + /*
>> + * Pair with smp_store_release() in ext4_block_zero_eof().
>> + * Ensure we see the updated i_ordered_lblk that was written
>> + * before the release store to i_ordered_len.
>> + */
>> + smp_rmb();
>> + order_lblk = READ_ONCE(ei->i_ordered_lblk);
>> + start = ioend->io_offset >> ioend->io_inode->i_blkbits;
>> + end = EXT4_B_TO_LBLK(ioend->io_inode,
>> + ioend->io_offset + ioend->io_size);
>> +
>> + if (start <= order_lblk && end >= order_lblk + order_len) {
>> + ioend->io_bio.bi_end_io = ext4_iomap_end_bio;
>> + ioend->io_private = (void *)EXT4_IOMAP_IOEND_ORDER_IO;
>> + ioend->io_flags |= IOMAP_IOEND_BOUNDARY;
>> + }
>> + }
>> +
>> return iomap_ioend_writeback_submit(wpc, error);
>> }
>>
>> @@ -4746,8 +4771,10 @@ static int ext4_iomap_submit_zero_block(struct inode *inode,
>> loff_t from, loff_t end)
>> {
>> struct address_space *mapping = inode->i_mapping;
>> + struct ext4_inode_info *ei = EXT4_I(inode);
>> struct folio *folio;
>> bool do_submit = false;
>> + int ret;
>>
>> folio = filemap_lock_folio(mapping, from >> PAGE_SHIFT);
>> if (IS_ERR(folio))
>> @@ -4757,14 +4784,50 @@ static int ext4_iomap_submit_zero_block(struct inode *inode,
>> folio_wait_writeback(folio);
>> WARN_ON_ONCE(folio_test_writeback(folio));
>>
>> - if (likely(folio_test_dirty(folio)))
>> + /*
>> + * Mark the ordered range. It will be cleared upon I/O completion
>> + * in ext4_iomap_end_bio(). Any operation that extends i_disksize
>> + * (including append write end io past the zeroed boundary,
>> + * truncate up and append fallocate) must wait for this I/O to
>> + * complete before updating i_disksize.
>> + *
>> + * When multiple overlapping unaligned EOF writes are in flight, we
>> + * only need to track and wait for the first one. Subsequent writes
>> + * will zero the gap in memory and ensure that the zeroed data is
>> + * written out along with the valid data in the same block before
>> + * i_disksize is updated.
>> + */
>> + if (likely(folio_test_dirty(folio) &&
>> + READ_ONCE(ei->i_ordered_len) == 0)) {
>> + WRITE_ONCE(ei->i_ordered_lblk,
>> + from >> inode->i_blkbits);
>> + /*
>> + * Pairs with smp_rmb() in ext4_iomap_writeback_submit()
>> + * and ext4_iomap_wb_ordered_wait(). Ensure the updated
>> + * i_ordered_lblk is visible when i_ordered_len becomes
>> + * non-zero.
>> + */
>> + smp_store_release(&ei->i_ordered_len, 1);
>> do_submit = true;
>> + }
>> folio_unlock(folio);
>> folio_put(folio);
>>
>> /* Submit zeroed block. */
>> - if (do_submit)
>> - return filemap_fdatawrite_range(mapping, from, end - 1);
>> + if (do_submit) {
>> + ret = filemap_fdatawrite_range(mapping, from, end - 1);
>> + if (ret) {
>> + /*
>> + * Pairs with wait_event() in
>> + * ext4_iomap_wb_ordered_wait(). Ensure
>> + * i_ordered_len = 0 is visible before waking up
>> + * waiters.
>> + */
>> + smp_store_release(&ei->i_ordered_len, 0);
>> + wake_up_all(&ei->i_ordered_wq);
>> + return ret;
>> + }
>> + }
>> return 0;
>> }
>>
>> @@ -4827,10 +4890,13 @@ int ext4_block_zero_eof(struct inode *inode, loff_t from, loff_t end)
>> * data=ordered mode. We submit zeroed range directly here.
>> * Do not wait for I/O completion for performance.
>> *
>> - * TODO: Any operation that extends i_disksize (including
>> - * append write end io past the zeroed boundary, truncate up,
>> - * and append fallocate) must wait for the relevant I/O to
>> - * complete before updating i_disksize.
>> + * The end_io handler ext4_iomap_wb_ordered_wait() will wait
>> + * for I/O completion before updating i_disksize if the write
>> + * extends beyond the zeroed boundary.
>> + *
>> + * TODO: Any other operation that extends i_disksize
>> + * (including truncate up and append fallocate) must wait for
>> + * the relevant I/O to complete before updating i_disksize.
>> */
>> } else if (ext4_inode_buffered_iomap(inode)) {
>> err = ext4_iomap_submit_zero_block(inode, from, end);
>> diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
>> index 3050c887329f..ad05ebb49bf6 100644
>> --- a/fs/ext4/page-io.c
>> +++ b/fs/ext4/page-io.c
>> @@ -613,6 +613,46 @@ int ext4_bio_write_folio(struct ext4_io_submit *io, struct folio *folio,
>> return 0;
>> }
>>
>> +/*
>> + * If the old disk size is not block size aligned and the current
>> + * writeback range is entirely beyond the old EOF block, we should
>> + * wait for the zeroed data written in ext4_block_zero_eof() to be
>> + * written out, otherwise, it may expose stale data in that block.
>> + */
>> +static void ext4_iomap_wb_ordered_wait(struct inode *inode,
>> + loff_t pos, loff_t end)
>> +{
>> + struct ext4_inode_info *ei = EXT4_I(inode);
>> + unsigned int blocksize = i_blocksize(inode);
>> + loff_t disksize = READ_ONCE(ei->i_disksize);
>> + ext4_lblk_t order_lblk, order_len;
>> +
>> + /*
>> + * Waiting for ordered I/O is unnecessary when:
>> + * - The on-disk size is block-aligned (no stale data exists).
>> + * - The write start is within the block of the old EOF
>> + * (overwriting, or appending to a block that already contains
>> + * valid data).
>> + */
>> + if (!(disksize & (blocksize - 1)) ||
>> + pos < round_up(disksize, blocksize))
>> + return;
>> +
>> + order_len = READ_ONCE(ei->i_ordered_len);
>> + if (!order_len)
>> + return;
>> +
>> + /*
>> + * Pair with smp_store_release() in ext4_iomap_end_bio() and
>> + * ext4_block_zero_eof(). Ensure we see the updated i_ordered_lblk
>> + * that was written before the release store to i_ordered_len.
>> + */
>> + smp_rmb();
>> + order_lblk = READ_ONCE(ei->i_ordered_lblk);
>> + if ((pos >> inode->i_blkbits) >= order_lblk + order_len)
>> + wait_event(ei->i_ordered_wq, READ_ONCE(ei->i_ordered_len) == 0);
>> +}
>> +
>> static int ext4_iomap_wb_update_disksize(handle_t *handle, struct inode *inode,
>> loff_t end)
>> {
>> @@ -656,6 +696,9 @@ static void ext4_iomap_finish_ioend(struct iomap_ioend *ioend)
>> goto out;
>> }
>>
>> + /* Wait ordered zero data to be written out. */
>> + ext4_iomap_wb_ordered_wait(inode, pos, pos + size);
>> +
>> /* We may need to convert one extent and dirty the inode. */
>> credits = ext4_chunk_trans_blocks(inode,
>> EXT4_MAX_BLOCKS(size, pos, inode->i_blkbits));
>> @@ -717,8 +760,25 @@ void ext4_iomap_end_bio(struct bio *bio)
>> struct inode *inode = ioend->io_inode;
>> struct ext4_inode_info *ei = EXT4_I(inode);
>> struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
>> + unsigned long io_mode = (unsigned long)ioend->io_private;
>> unsigned long flags;
>>
>> + /*
>> + * This is an ordered I/O, clear the ordered range set in
>> + * ext4_block_zero_eof() and wake up all waiters that will update
>> + * the inode i_disksize.
>> + */
>> + if (io_mode == EXT4_IOMAP_IOEND_ORDER_IO) {
>> + /*
>> + * Pairs with wait_event() in ext4_iomap_wb_ordered_wait().
>> + * Ensure i_ordered_len = 0 is visible before waking up
>> + * waiters.
>> + */
>> + smp_store_release(&ei->i_ordered_len, 0);
>> + wake_up_all(&ei->i_ordered_wq);
>> + goto defer;
>> + }
>> +
>> /* Needs to convert unwritten extents or update the i_disksize. */
>> if ((ioend->io_flags & IOMAP_IOEND_UNWRITTEN) ||
>> ioend->io_offset + ioend->io_size > READ_ONCE(ei->i_disksize))
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 62bfe05a64bc..9c0a00e716f3 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1444,6 +1444,9 @@ static struct inode *ext4_alloc_inode(struct super_block *sb)
>> ext4_fc_init_inode(&ei->vfs_inode);
>> spin_lock_init(&ei->i_fc_lock);
>> mmb_init(&ei->i_metadata_bhs, &ei->vfs_inode.i_data);
>> + ei->i_ordered_lblk = 0;
>> + ei->i_ordered_len = 0;
>> + init_waitqueue_head(&ei->i_ordered_wq);
>> return &ei->vfs_inode;
>> }
>>
>> @@ -1480,12 +1483,20 @@ static void ext4_destroy_inode(struct inode *inode)
>> dump_stack();
>> }
>>
>> - if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ERROR_FS) &&
>> - WARN_ON_ONCE(EXT4_I(inode)->i_reserved_data_blocks))
>> - ext4_msg(inode->i_sb, KERN_ERR,
>> - "Inode %llu (%p): i_reserved_data_blocks (%u) not cleared!",
>> - inode->i_ino, EXT4_I(inode),
>> - EXT4_I(inode)->i_reserved_data_blocks);
>> + if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ERROR_FS)) {
>> + if (WARN_ON_ONCE(EXT4_I(inode)->i_reserved_data_blocks))
>> + ext4_msg(inode->i_sb, KERN_ERR,
>> + "Inode %llu (%p): i_reserved_data_blocks (%u) not cleared!",
>> + inode->i_ino, EXT4_I(inode),
>> + EXT4_I(inode)->i_reserved_data_blocks);
>> +
>> + if (WARN_ON_ONCE(EXT4_I(inode)->i_ordered_len))
>> + ext4_msg(inode->i_sb, KERN_ERR,
>> + "Inode %llu (%p): i_ordered_lblk (%u) and i_ordered_len (%u) not cleared!",
>> + inode->i_ino, EXT4_I(inode),
>> + EXT4_I(inode)->i_ordered_lblk,
>> + EXT4_I(inode)->i_ordered_len);
>> + }
>> }
>>
>> static void ext4_shutdown(struct super_block *sb)
>> --
>> 2.52.0
>>
next prev parent reply other threads:[~2026-06-22 3:32 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 7:23 [PATCH v4 00/23] ext4: use iomap for regular file's buffered I/O path Zhang Yi
2026-05-11 7:23 ` [PATCH v4 01/23] ext4: simplify size updating in ext4_setattr() Zhang Yi
2026-05-19 5:24 ` Ojaswin Mujoo
2026-05-11 7:23 ` [PATCH v4 02/23] ext4: factor out ext4_truncate_[up|down]() Zhang Yi
2026-05-19 6:05 ` Ojaswin Mujoo
2026-06-16 9:31 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 03/23] ext4: simplify error handling in ext4_setattr() Zhang Yi
2026-05-19 6:08 ` Ojaswin Mujoo
2026-06-16 9:36 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 04/23] ext4: add iomap address space operations for buffered I/O Zhang Yi
2026-05-19 9:28 ` Ojaswin Mujoo
2026-05-19 12:35 ` Zhang Yi
2026-05-19 16:53 ` Ojaswin Mujoo
2026-05-20 2:49 ` Zhang Yi
2026-05-26 17:11 ` Ojaswin Mujoo
2026-05-11 7:23 ` [PATCH v4 05/23] ext4: implement buffered read path using iomap Zhang Yi
2026-05-19 10:00 ` Ojaswin Mujoo
2026-05-11 7:23 ` [PATCH v4 06/23] ext4: pass out extent seq counter when mapping da blocks Zhang Yi
2026-05-19 10:02 ` Ojaswin Mujoo
2026-06-16 10:04 ` Jan Kara
2026-06-16 12:37 ` Zhang Yi
2026-06-17 20:29 ` Jan Kara
2026-06-18 1:43 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 07/23] ext4: do not use data=ordered mode for inodes using buffered iomap path Zhang Yi
2026-05-19 10:41 ` Ojaswin Mujoo
2026-05-19 13:31 ` Ojaswin Mujoo
2026-05-20 8:18 ` Zhang Yi
2026-05-20 13:17 ` Ojaswin Mujoo
2026-06-16 10:01 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 08/23] ext4: implement buffered write path using iomap Zhang Yi
2026-05-26 17:10 ` Ojaswin Mujoo
2026-05-28 15:40 ` Darrick J. Wong
2026-06-02 7:02 ` Ojaswin Mujoo
2026-05-29 9:13 ` Zhang Yi
2026-06-02 10:05 ` Ojaswin Mujoo
2026-06-03 1:44 ` Zhang Yi
2026-06-02 10:26 ` Ojaswin Mujoo
2026-06-03 2:56 ` Zhang Yi
2026-06-03 11:08 ` Ojaswin Mujoo
2026-06-16 10:45 ` Jan Kara
2026-06-16 14:42 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 09/23] ext4: implement writeback " Zhang Yi
2026-05-27 12:49 ` Ojaswin Mujoo
2026-05-29 14:12 ` Zhang Yi
2026-05-29 15:32 ` Ojaswin Mujoo
2026-05-30 1:21 ` Zhang Yi
2026-06-01 6:26 ` Ojaswin Mujoo
2026-06-16 11:47 ` Jan Kara
2026-06-22 12:36 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 10/23] ext4: implement mmap " Zhang Yi
2026-05-27 12:56 ` Ojaswin Mujoo
2026-06-16 11:56 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 11/23] iomap: correct the range of a partial dirty clear Zhang Yi
2026-05-11 7:46 ` Christoph Hellwig
2026-05-11 8:57 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 12/23] iomap: support invalidating partial folios Zhang Yi
2026-05-11 7:23 ` [PATCH v4 13/23] iomap: fix incorrect did_zero setting in iomap_zero_iter() Zhang Yi
2026-05-11 7:23 ` [PATCH v4 14/23] ext4: implement partial block zero range path using iomap Zhang Yi
2026-05-27 13:13 ` Ojaswin Mujoo
2026-06-16 12:28 ` Jan Kara
2026-06-17 8:14 ` Zhang Yi
2026-06-17 10:50 ` Jan Kara
2026-06-17 13:00 ` Zhang Yi
2026-06-17 10:56 ` Brian Foster
2026-06-17 13:22 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 15/23] ext4: add block mapping tracepoints for iomap buffered I/O path Zhang Yi
2026-05-27 13:14 ` Ojaswin Mujoo
2026-06-16 12:29 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 16/23] ext4: disable online defrag when inode using " Zhang Yi
2026-05-27 13:14 ` Ojaswin Mujoo
2026-06-16 12:30 ` Jan Kara
2026-05-11 7:23 ` [PATCH v4 17/23] ext4: submit zeroed post-EOF data immediately in the " Zhang Yi
2026-05-27 13:41 ` Ojaswin Mujoo
2026-05-30 2:53 ` Zhang Yi
2026-06-01 9:08 ` Ojaswin Mujoo
2026-06-01 12:22 ` Zhang Yi
2026-06-01 18:15 ` Ojaswin Mujoo
2026-06-02 3:36 ` Zhang Yi
2026-06-18 12:59 ` Jan Kara
2026-06-22 3:37 ` Zhang Yi
2026-05-11 7:23 ` [PATCH v4 18/23] ext4: wait for ordered I/O " Zhang Yi
2026-05-27 15:58 ` Ojaswin Mujoo
2026-05-28 13:34 ` Ojaswin Mujoo
2026-05-30 9:32 ` Zhang Yi
2026-06-02 5:56 ` Ojaswin Mujoo
2026-05-30 7:22 ` Zhang Yi
2026-05-30 8:24 ` Zhang Yi
2026-06-01 18:33 ` Ojaswin Mujoo
2026-06-02 3:22 ` Zhang Yi
2026-06-02 5:35 ` Ojaswin Mujoo
2026-06-18 13:48 ` Jan Kara
2026-06-22 3:32 ` Zhang Yi [this message]
2026-05-11 7:23 ` [PATCH v4 19/23] ext4: update i_disksize to i_size on ordered I/O completion Zhang Yi
2026-05-11 7:23 ` [PATCH v4 20/23] ext4: wait for ordered I/O to complete during insert and collapse range Zhang Yi
2026-05-11 7:23 ` [PATCH v4 21/23] ext4: add tracepoints for ordered I/O in the iomap buffered I/O path Zhang Yi
2026-05-11 7:23 ` [PATCH v4 22/23] ext4: partially enable iomap for the buffered I/O path of regular files Zhang Yi
2026-05-11 7:23 ` [PATCH v4 23/23] ext4: introduce a mount option for iomap buffered I/O path 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=9ab9281d-c5dc-4183-8bc9-b53b5a4ac9c0@gmail.com \
--to=yizhang089@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--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 \
--cc=yukuai@fnnas.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