On Sun, Jun 8, 2025 at 9:45 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Fri, Jun 06, 2025 at 04:37:57PM -0700, Joanne Koong wrote: > > Add a new iomap type, IOMAP_IN_MEM, that represents data that resides in > > memory and does not map to or depend on the block layer and is not > > embedded inline in an inode. This will be used for example by filesystems > > such as FUSE where the data is in memory or needs to be fetched from a > > server and is not coupled with the block layer. This lets these > > filesystems use some of the internal features in iomaps such as > > granular dirty tracking for large folios. > > How does this differ from the naming of the existing flags? > > Nothing here explains why we need a new type vs reusing the existing > ones. I'll update this commit message in v2. IOMAP_INLINE is the closest in idea to what I'm looking for in that it's completely independent from block io, but it falls short in a few ways (described in the reply to Darrick in [1]). In terms of implementation logic, IOMAP_MAPPED fits great but that's tied in idea to mapped blocks and we'd be unable to make certain assertions (eg if the iomap type doesn't use bios, the caller must provide ->read_folio_sync() and ->writeback_folio() callbacks). [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1aXtMcUsmZPCjre1u2=mDPhk5W5Jzp8HOS+ASxkby1+Lw@xxxxxxxxxxxxxx/T/#ma71d1befb676b948c34f170aa687738133f5907a >
