Re: [PATCH v1 2/8] iomap: add IOMAP_IN_MEM iomap type

["Darrick J. Wong" <djwong@kernel.org>]

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@gmail.com>
> ---
>  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
> 
>