On Tue, Jun 10, 2025 at 06:29:10AM -0700, Christoph Hellwig wrote: > On Tue, Jun 10, 2025 at 08:21:06AM -0400, Brian Foster wrote: > > Yes.. but I'm not totally sure wrt impact on the fbatch checks quite > > yet. The next thing I wanted to look at is addressing the same unwritten > > mapping vs. dirty folios issue in the seek data/hole path. It's been a > > little while since I last investigated there (and that was also before > > the whole granular advance approach was devised), but IIRC it would look > > rather similar to what this is doing for zero range. That may or may > > not justify just making the batch required for both operations and > > potentially simplifying this logic further. I'll keep that in mind when > > I get to it.. > > On thing that the batch would be extremely useful for is making > iomap_file_unshare not totally suck by reading in all folios for a > range (not just the dirty ones) similar to the filemap_read path > instead of synchronously reading one block at a time. > I can add it to the list to look into. On a quick look though any reason we wouldn't want to just invoke readahead or something somewhere in that loop, particularly if that is mainly a performance issue..? Brian
