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

[Christoph Hellwig <hch@infradead.org>]

On Tue, Jun 10, 2025 at 11:00:51PM -0700, Joanne Koong wrote:
> Not a great idea, but theoretically we could stash that info (offset
> and len) in the folio->private iomap_folio_state struct. I don't think
> that runs into synchronization issues since it would be set and
> cleared while the file lock is held for that read.

Yeah, I thought about it, but there's no simple hole, so we'd bloat
a long living structure for short-term argument passing.

So I've been thinking of maybe sticking to something similar to
your version, but with a few tweaks.  Let me cook up a patch for
review.

> But regardless I think we still need a new variant of read_folio
> because if a non block-io iomap wants to use iomap_read_folio() /
> iomap_readahead() for the granular uptodate parsing logic that's in
> there, it'll need to provide a method for reading a partial folio. I
> initially wasn't planning to have fuse use iomap_read_folio() /
> iomap_readahead() but I realized there's some cases where fuse will
> find it useful, so i'm planning to add that in.

Heh.  How much of the iomap code can you reuse vs just using another
variant that shareds the uptodate/dirty bitmaps?

> > variant of read_folio that allows partial reads might still be nicer
> > than a iomap_folio_op.  Let me draft that and see if willy or other mm
> > folks choke on it :)
> 
> writeback_folio() is also a VM level concept so under that same logic,
> should writeback_folio() also be an address space operation?

Not really.  Yes, writing back a part of a folio is high level in
concept, but you really need quite a lot of iomap speific in practive.

> 
> A more general question i've been trying to figure out is if the
> vision is that iomap is going to be the defacto generic library that
> all/most filesystems will be using in the future?

That's always been my plan.  But it's not been overly successful
so far.

> If so then it makes
> sense to me to add this to the address space operations but if not
> then I don't think I see the hate for having the folio callbacks be
> embedded in iomap_folio_op.

I'd really avoid sticking something that is just a callback into the
address_space operations.  We've done that for write_begin/write_end
and it has turned out to be a huge mess.  Something in the aops
must be callable standalone and not depend on a very specific caller
context.