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 using IOMAP_INLINE and setting iomap::inline_data = kmap_local_folio(...)? Is the situation here that FUSE already /has/ a folio from the mapping, so all you really need iomap to do is manage the folio's uptodate/dirty state? --D > Signed-off-by: Joanne Koong <joannelkoong@xxxxxxxxx> > --- > include/linux/iomap.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > index 68416b135151..dbbf217eb03f 100644 > --- a/include/linux/iomap.h > +++ b/include/linux/iomap.h > @@ -30,6 +30,7 @@ struct vm_fault; > #define IOMAP_MAPPED 2 /* blocks allocated at @addr */ > #define IOMAP_UNWRITTEN 3 /* blocks allocated at @addr in unwritten state */ > #define IOMAP_INLINE 4 /* data inline in the inode */ > +#define IOMAP_IN_MEM 5 /* data in memory, does not map to blocks */ > > /* > * Flags reported by the file system from iomap_begin: > -- > 2.47.1 > >
