On Fri, Jun 12, 2026 at 03:19:30PM +0800, Gao Xiang wrote: > > > On 2026/6/12 15:10, Christoph Hellwig wrote: > > On Fri, Jun 12, 2026 at 02:54:47PM +0800, Gao Xiang wrote: > > > 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): > > > > That should work too for your case. But we definitively have various > > cases where merging over iomaps is a bad idea. You'll also end up with > > other efficiency gains by merging consecutive entries, especially for > > direct I/O and when using large folios. > > Yes, optimizing erofs chunk mapping would be more > efficient, will work out one soon, but Yifan can test > your patch in parallel. > > Also, if "iomap: submit read bio after each extent" is > applied, I guess some merging condition in > iomap_bio_read_folio_range() can be removed since they > won't be reached in any case. (deadcode)
I guess we can't hit the sector check anymore indeed, assuming we never get non-contiguos readeahead requests, which I think is true.
