On Mon, Jun 9, 2025 at 5:47 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Fri, Jun 06, 2025 at 04:37:55PM -0700, Joanne Koong wrote: > > This series adds fuse iomap support for buffered writes and dirty folio > > writeback. This is needed so that granular dirty tracking can be used in > > fuse when large folios are enabled so that if only a few bytes in a large > > folio are dirty, only a smaller portion is written out instead of the entire > > folio. > > > > In order to do so, a new iomap type, IOMAP_IN_MEM, is added that is more > > generic and does not depend on the block layer. The parts of iomap buffer io > > that depend on bios and CONFIG_BLOCK is moved to a separate file, > > buffered-io-bio.c, in order to allow filesystems that do not have CONFIG_BLOCK > > set to use IOMAP_IN_MEM buffered io. > > > > This series was run through fstests with large folios enabled and through > > some quick sanity checks on passthrough_hp with a) writing 1 GB in 1 MB chunks > > and then going back and dirtying a few bytes in each chunk and b) writing 50 MB > > in 1 MB chunks and going through dirtying the entire chunk for several runs. > > a) showed about a 40% speedup increase with iomap support added and b) showed > > roughly the same performance. > > > > This patchset does not enable large folios yet. That will be sent out in a > > separate future patchset. > > > > > > Thanks, > > Joanne > > > > Joanne Koong (8): > > iomap: move buffered io bio logic into separate file > > iomap: add IOMAP_IN_MEM iomap type > > iomap: add buffered write support for IOMAP_IN_MEM iomaps > > iomap: add writepages support for IOMAP_IN_MEM iomaps > > 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. > > Hence it seems like this patchset is trying to duplicate > functionality that netfs already provides request/response > protocol-based filesystems, but with much less generic functionality > than netfs already provides.... > > Hence I'm not seeing why this IO patch was chosen for FUSE. Was > netfs considered as a candidate infrastructure large folio support > for FUSE? If so, why was iomap chosen over netfs? If not, would FUSE > be better suited to netfs integration than hacking fuse specific "no > block mapping" IO paths into infrastructure specifically optimised > for block based filesystems? Hi Dave, The main reason I chose iomap was because it has granular dirty and uptodate tracking for large folios, which I didn't see that netfs has (yet?). That's the main thing fuse needs. When I took a look at it, it didnt' seem to me that fuse mapped that neatly to netfs - for example it wouldn't use netfs_io_requests or netfs_io_streams or rolling buffers. Netfs seemed to have a bunch of extra stuff that would have made it messier for fuse to be integrated into, whereas the iomap library (except for the bio dependency) seemed more generic/minimalistic > > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
