On Thu, Jun 18, 2026 at 10:01 PM Christoph Hellwig <[email protected]> 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. > > So instead of adding more checks move over to a model where a bio > only spans a single iomap. File systems can still create iomap > that span more than an extent if they want to build larger I/O. > > Reported-by: Kelu Ye <[email protected]> > Reported-by: Yifan Zhao <[email protected]> > Signed-off-by: Christoph Hellwig <[email protected]> > --- > fs/iomap/buffered-io.c | 22 ++++++++++++++-------- > 1 file changed, 14 insertions(+), 8 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 8d4806dc46d4..7449cfd995d5 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -524,6 +524,14 @@ static void iomap_read_end(struct folio *folio, size_t > bytes_submitted) > } > } > > +static void iomap_read_submit(struct iomap_iter *iter, > + struct iomap_read_folio_ctx *ctx) > +{ > + if (ctx->read_ctx && ctx->ops->submit_read) > + ctx->ops->submit_read(iter, ctx); > + ctx->read_ctx = NULL;
Does it make sense to move this line to the bio submit_read callback instead of unconditionally clearing it here? If we clear it here, I think this makes read_ctx only able to hold per-mapping state instead of also being able to hold persistent state across mappings. fuse currently uses read_ctx to hold per-request state (though this patch wouldn't break anything since fuse only ever returns one mapping covering the whole request). Thanks, Joanne
