On Tue, Jun 10, 2025 at 10:47:39AM +1000, Dave Chinner wrote: > AFAICT, this is just adding a synchronous "read folio" and "write > folio" hooks into iomapi that bypass the existing "map and pack" > bio-based infrastructure. i.e. there is no actual "iomapping" being > done, it's adding special case IO hooks into the IO back end > iomap bio interfaces. > > Is that a fair summary of what this is doing? > > If so, given that FUSE is actually a request/response protocol, > why wasn't netfs chosen as the back end infrastructure to support > large folios in the FUSE pagecache? > > It's specifically designed for request/response IO interfaces that > are not block IO based, and it has infrastructure such as local file > caching built into it for optimising performance on high latency/low > bandwidth network based filesystems. Has it? Or was that part of netfs simply written because Dave didn't listen when I explained him that the iterate over file range part of iomap is perfectly fine for network file systems? I'd still like to see that part of networking file systems moved over to iomap, and I think it will have to happen if netfs wants to add nfs support. Because with nfs we can suddently end up in the block I/O path for a nominal network file system in the block layout, and that could reuse all the existing iomap code..
