From: Christoph Hellwig <hch@infradead.org>
To: Zhang Yi <yi.zhang@huawei.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, jack@suse.cz, ojaswin@linux.ibm.com,
ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org,
yi.zhang@huaweicloud.com, yizhang089@gmail.com,
libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com
Subject: Re: [PATCH -next v2 00/22] ext4: use iomap for regular file's buffered I/O path
Date: Mon, 2 Feb 2026 22:43:19 -0800 [thread overview]
Message-ID: <aYGZB_hugPRXCiSI@infradead.org> (raw)
In-Reply-To: <20260203062523.3869120-1-yi.zhang@huawei.com>
> Original Cover (Updated):
This really should always be first. The updates are rather minor
compared to the overview that the cover letter provides.
> Key notes on the iomap implementations in this series.
> - Don't use ordered data mode to prevent exposing stale data when
> performing append write and truncating down.
I can't parse this.
> - Override dioread_nolock mount option, always allocate unwritten
> extents for new blocks.
Why do you override it?
> - When performing write back, don't use reserved journal handle and
> postponing updating i_disksize until I/O is done.
Again missing the why and the implications.
> buffered write
> ==============
>
> buffer_head:
> bs write cache uncached write
> 1k 423 MiB/s 36.3 MiB/s
> 4k 1067 MiB/s 58.4 MiB/s
> 64k 4321 MiB/s 869 MiB/s
> 1M 4640 MiB/s 3158 MiB/s
>
> iomap:
> bs write cache uncached write
> 1k 403 MiB/s 57 MiB/s
> 4k 1093 MiB/s 61 MiB/s
> 64k 6488 MiB/s 1206 MiB/s
> 1M 7378 MiB/s 4818 MiB/s
This would read better if you actually compated buffered_head
vs iomap side by side.
What is the bs? The read unit size? I guess not the file system
block size as some of the values are too large for that.
Looks like iomap is faster, often much faster except for the
1k cached case, where it is slightly slower. Do you have
any idea why?
> buffered read
> =============
>
> buffer_head:
> bs read hole read cache read data
> 1k 635 MiB/s 661 MiB/s 605 MiB/s
> 4k 1987 MiB/s 2128 MiB/s 1761 MiB/s
> 64k 6068 MiB/s 9472 MiB/s 4475 MiB/s
> 1M 5471 MiB/s 8657 MiB/s 4405 MiB/s
>
> iomap:
> bs read hole read cache read data
> 1k 643 MiB/s 653 MiB/s 602 MiB/s
> 4k 2075 MiB/s 2159 MiB/s 1716 MiB/s
> 64k 6267 MiB/s 9545MiB/s 4451 MiB/s
> 1M 6072 MiB/s 9191MiB/s 4467 MiB/s
What is read cache vs read data here?
Otherwise same comments as for the write case.
next prev parent reply other threads:[~2026-02-03 6:43 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 6:25 [PATCH -next v2 00/22] ext4: use iomap for regular file's buffered I/O path Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 01/22] ext4: make ext4_block_zero_page_range() pass out did_zero Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 02/22] ext4: make ext4_block_truncate_page() return zeroed length Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 03/22] ext4: only order data when partially block truncating down Zhang Yi
2026-02-03 9:59 ` Jan Kara
2026-02-04 6:42 ` Zhang Yi
2026-02-04 14:18 ` Jan Kara
2026-02-05 3:27 ` Baokun Li
2026-02-05 14:07 ` Jan Kara
2026-02-06 1:14 ` Baokun Li
2026-02-05 7:50 ` Zhang Yi
2026-02-05 15:05 ` Jan Kara
2026-02-06 11:09 ` Zhang Yi
2026-02-06 15:35 ` Jan Kara
2026-02-09 8:28 ` Zhang Yi
2026-02-10 12:02 ` Zhang Yi
2026-02-10 14:07 ` Jan Kara
2026-02-10 16:11 ` Zhang Yi
2026-02-11 11:42 ` Jan Kara
2026-02-11 13:38 ` Zhang Yi
2026-02-04 4:21 ` kernel test robot
2026-02-10 7:05 ` Ojaswin Mujoo
2026-02-10 15:57 ` Zhang Yi
2026-02-11 15:23 ` Ojaswin Mujoo
2026-02-03 6:25 ` [PATCH -next v2 04/22] ext4: factor out journalled block zeroing range Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 05/22] ext4: stop passing handle to ext4_journalled_block_zero_range() Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 06/22] ext4: don't zero partial block under an active handle when truncating down Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 07/22] ext4: move ext4_block_zero_page_range() out of an active handle Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 08/22] ext4: zero post EOF partial block before appending write Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 09/22] ext4: add a new iomap aops for regular file's buffered IO path Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 10/22] ext4: implement buffered read iomap path Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 11/22] ext4: pass out extent seq counter when mapping da blocks Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 12/22] ext4: implement buffered write iomap path Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 13/22] ext4: implement writeback " Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 14/22] ext4: implement mmap " Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 15/22] iomap: correct the range of a partial dirty clear Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 16/22] iomap: support invalidating partial folios Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 17/22] ext4: implement partial block zero range iomap path Zhang Yi
2026-02-04 0:21 ` kernel test robot
2026-02-03 6:25 ` [PATCH -next v2 18/22] ext4: do not order data for inodes using buffered " Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 19/22] ext4: add block mapping tracepoints for iomap buffered I/O path Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 20/22] ext4: disable online defrag when inode using " Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 21/22] ext4: partially enable iomap for the buffered I/O path of regular files Zhang Yi
2026-02-03 6:25 ` [PATCH -next v2 22/22] ext4: introduce a mount option for iomap buffered I/O path Zhang Yi
2026-02-03 6:43 ` Christoph Hellwig [this message]
2026-02-03 9:18 ` [PATCH -next v2 00/22] ext4: use iomap for regular file's " Zhang Yi
2026-02-03 13:14 ` Theodore Tso
2026-02-04 1:33 ` Zhang Yi
2026-02-04 1:59 ` Baokun Li
2026-02-04 14:23 ` Jan Kara
2026-02-05 2:06 ` Zhang Yi
2026-02-05 3:04 ` Baokun Li
2026-02-05 12:58 ` Jan Kara
2026-02-06 2:15 ` Zhang Yi
2026-02-05 2:55 ` Baokun Li
2026-02-05 12:46 ` Jan Kara
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=aYGZB_hugPRXCiSI@infradead.org \
--to=hch@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=djwong@kernel.org \
--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=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=yizhang089@gmail.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