From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Christian Brauner <brauner@kernel.org>,
Kelu Ye <yekelu1@huawei.com>, Yifan Zhao <zhaoyifan28@huawei.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
Joanne Koong <joannelkoong@gmail.com>,
Namjae Jeon <linkinjeon@kernel.org>,
Sungjong Seo <sj1557.seo@samsung.com>,
Hyunchul Lee <hyc.lee@gmail.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel@lists.linux.dev, ntfs3@lists.linux.dev,
linux-erofs@lists.ozlabs.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] iomap: submit read bio after each extent
Date: Fri, 26 Jun 2026 06:31:17 +0200 [thread overview]
Message-ID: <20260626043117.GB8078@lst.de> (raw)
In-Reply-To: <20260625174758.GE6078@frogsfrogsfrogs>
On Thu, Jun 25, 2026 at 10:47:58AM -0700, Darrick J. Wong wrote:
> On Thu, Jun 25, 2026 at 02:07:57PM +0200, Christoph Hellwig wrote:
> > Currently the iomap buffered read path tries to build up read context
> > (i.e. bios for the typical block based case) over multiple iomaps as
> > long as the sector matches. This does not take into account files
> > that can map to multiple different devices. While this could be fixed
> > by a bdev check in iomap_bio_read_folio_range, the building up of I/O
> > over iomaps actually was a problem for the not yet merged ext2 iomap
> > port, as that does want to send out I/O at the end of an indirect
> > block mapped range.
>
> This really puts the onus on block-mapped filesystems (e.g. ext2) to
> merge adjacent maps into extents. Granted they *probably* already have
> been doing that.
Yes. In fact the ext2 conversion was the first ask for this change,
because they do not want unlimited merging but kick off I/O at the
indirect block boundary.
> > So instead of adding more checks move over to a model where a bio only
> > spans a single iomap. Change ->submit_read to be called after each
> > iteration, and pass a force argument to indicate that the bio must
> > be submitted set on the last iteration. Switch the bio based users
> > to always submit, while keeping the single submit for fuse.
>
> Is fuse the sole reason for the "force" parameter to exist? I wonder if
> fuse could drop its submit_read function and call fuse_send_readpages
> after the iomap_read{ahead,folio} function returns?
Probably..
next prev parent reply other threads:[~2026-06-26 4:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 12:07 don't build bios/contexts over multiple iomaps v3 Christoph Hellwig
2026-06-25 12:07 ` [PATCH 1/2] iomap: consolidate bio submission Christoph Hellwig
2026-06-25 17:27 ` Darrick J. Wong
2026-06-26 4:30 ` Christoph Hellwig
2026-06-25 12:07 ` [PATCH 2/2] iomap: submit read bio after each extent Christoph Hellwig
2026-06-25 17:47 ` Darrick J. Wong
2026-06-25 18:32 ` Joanne Koong
2026-06-26 4:33 ` Christoph Hellwig
2026-06-26 6:16 ` Christoph Hellwig
2026-06-26 6:20 ` Darrick J. Wong
2026-06-26 14:51 ` Joanne Koong
2026-06-26 4:31 ` Christoph Hellwig [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-06-23 13:51 don't build bios/contexts over multiple iomaps v2 Christoph Hellwig
2026-06-23 13:51 ` [PATCH 2/2] iomap: submit read bio after each extent Christoph Hellwig
2026-06-23 17:29 ` Joanne Koong
2026-06-24 7:34 ` Christoph Hellwig
2026-06-23 23:58 ` Namjae Jeon
2026-06-24 7:42 ` zhaoyifan (H)
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=20260626043117.GB8078@lst.de \
--to=hch@lst.de \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=fuse-devel@lists.linux.dev \
--cc=hyc.lee@gmail.com \
--cc=joannelkoong@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=ntfs3@lists.linux.dev \
--cc=ritesh.list@gmail.com \
--cc=sj1557.seo@samsung.com \
--cc=yekelu1@huawei.com \
--cc=zhaoyifan28@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.