From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Yifan Zhao <zhaoyifan28@huawei.com>,
linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
yekelu1@huawei.com, jingrui@huawei.com, zhukeqian1@huawei.com,
Ritesh Harjani <ritesh.list@gmail.com>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, Joanne Koong <joannelkoong@gmail.com>
Subject: Re: don't merge bios over iomap boundaries, was: Re: [PATCH] erofs: prevent buffered read bio merges across device chunks
Date: Fri, 12 Jun 2026 14:54:47 +0800 [thread overview]
Message-ID: <62f6e9bc-cfb3-441c-a3b7-301b8649f0ae@linux.alibaba.com> (raw)
In-Reply-To: <aiumQL8LEWQX_Nag@infradead.org>
Hi Christoph,
On 2026/6/12 14:25, Christoph Hellwig wrote:
> On Fri, Jun 12, 2026 at 11:42:38AM +0800, Gao Xiang wrote:
>>> Reported-by: Kelu Ye <yekelu1@huawei.com>
>>> Assisted-by: Codex:GPT-5.5
>>> Signed-off-by: Yifan Zhao <zhaoyifan28@huawei.com>
>>
>> I think it's an iomap bug instead, see:
>>
>> iomap_bio_read_folio_range(), we should fix iomap instead.
>
> Yes. iomap should not try to build bios over iomap boundaries.
> caused various issues. Ritesh ran into that with the ext2 port
> back in the day, and I actually ran into it again with an under
> development xfs feature.
>
> Can you try this patch?
hmm, currently erofs could return block-sized iomap (if the chunk
size is 4k) even it can be merged with the following chunks.
Previously it was fairly good since consecutive chunks will be
added to the current bio if possible, but after this patch,
there will be a lot of 4k bios.
But if iomap goes into this way, I could make iomap_begin maps
more chunks in one shot, but that needs more changes in erofs,
it's fine anyway.
... I was thinking the following diff (space-damaged):
diff --git a/fs/iomap/bio.c b/fs/iomap/bio.c
index 4504f4633f17..241df96a16a6 100644
--- a/fs/iomap/bio.c
+++ b/fs/iomap/bio.c
@@ -142,6 +142,7 @@ int iomap_bio_read_folio_range(const struct iomap_iter *iter,
if (!bio ||
bio_end_sector(bio) != iomap_sector(&iter->iomap, iter->pos) ||
+ bio->bi_bdev != iter->iomap.bdev ||
bio->bi_iter.bi_size > iomap_max_bio_size(&iter->iomap) - plen ||
!bio_add_folio(bio, folio, plen, offset_in_folio(folio, iter->pos)))
iomap_read_alloc_bio(iter, ctx, plen);
but either way works fine with me since it's an iomap design
stuff.
Thanks,
Gao Xiang
>
> ---
> From 297230cc3c08cbfef3670b08c4e35813c18c523e Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Sun, 7 Jun 2026 08:53:20 +0200
> Subject: iomap: submit read bio after each extent
>
> This keeps bios from crossing RTG boundaries in XFS and probably fixes
> all kinds of other stuff..
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/iomap/buffered-io.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index d55b936e6986..3642a11c102f 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -597,12 +597,13 @@ void iomap_read_folio(const struct iomap_ops *ops,
>
> trace_iomap_readpage(iter.inode, 1);
>
> - while ((ret = iomap_iter(&iter, ops)) > 0)
> + while ((ret = iomap_iter(&iter, ops)) > 0) {
> iter.status = iomap_read_folio_iter(&iter, ctx,
> &bytes_submitted);
> -
> - if (ctx->read_ctx && ctx->ops->submit_read)
> - ctx->ops->submit_read(&iter, ctx);
> + if (ctx->read_ctx && ctx->ops->submit_read)
> + ctx->ops->submit_read(&iter, ctx);
> + ctx->read_ctx = NULL;
> + }
>
> if (ctx->cur_folio)
> iomap_read_end(ctx->cur_folio, bytes_submitted);
> @@ -664,12 +665,13 @@ void iomap_readahead(const struct iomap_ops *ops,
>
> trace_iomap_readahead(rac->mapping->host, readahead_count(rac));
>
> - while (iomap_iter(&iter, ops) > 0)
> + while (iomap_iter(&iter, ops) > 0) {
> iter.status = iomap_readahead_iter(&iter, ctx,
> &cur_bytes_submitted);
> -
> - if (ctx->read_ctx && ctx->ops->submit_read)
> - ctx->ops->submit_read(&iter, ctx);
> + if (ctx->read_ctx && ctx->ops->submit_read)
> + ctx->ops->submit_read(&iter, ctx);
> + ctx->read_ctx = NULL;
> + }
>
> if (ctx->cur_folio)
> iomap_read_end(ctx->cur_folio, cur_bytes_submitted);
next prev parent reply other threads:[~2026-06-12 6:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 3:32 Yifan Zhao
2026-06-12 3:42 ` Gao Xiang
2026-06-12 6:25 ` don't merge bios over iomap boundaries, was: " Christoph Hellwig
2026-06-12 6:54 ` Gao Xiang [this message]
2026-06-12 7:10 ` Christoph Hellwig
2026-06-12 7:19 ` Gao Xiang
2026-06-12 7:35 ` Gao Xiang
2026-06-12 8:04 ` Christoph Hellwig
2026-06-12 8:01 ` Christoph Hellwig
2026-06-18 7:16 ` zhaoyifan (H)
2026-06-18 9:00 ` Christoph Hellwig
2026-06-18 10:14 ` Gao Xiang
2026-06-18 10:27 ` Christoph Hellwig
2026-06-18 10:53 ` Gao Xiang
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=62f6e9bc-cfb3-441c-a3b7-301b8649f0ae@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jingrui@huawei.com \
--cc=joannelkoong@gmail.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=yekelu1@huawei.com \
--cc=zhaoyifan28@huawei.com \
--cc=zhukeqian1@huawei.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
all inboxes | Powered by JetHome®