Re: LSF/MM/BPF 2023 IOMAP conversion status update

[Matthew Wilcox <willy@infradead.org>]

On Mon, Feb 27, 2023 at 11:26:17AM -0800, Darrick J. Wong wrote:
> > As I wrote above, for metadata there ought to be something as otherwise it
> > will be real pain (and no gain really). But I guess the concrete API only
> > matterializes once we attempt a conversion of some filesystem like ext2.
> > I'll try to have a look into that, at least the obvious preparatory steps
> > like converting the data paths to iomap.
> 
> willy's tried this.

Well, I started on it.  The first thing I looked at was trying to decide
how to handle the equivalent of BH_boundary:

https://lore.kernel.org/linux-fsdevel/20200320144014.3276-1-willy@infradead.org/

I'm no longer sure that's the right approach.  Maybe we do want to have
an IOMAP_F_BOUNDARY to indicate that the bio should be submitted before
calling iomap_iter() again.  But we're definitely still missing the piece
where we start the I/O to the page by setting iop->read_bytes_pending
to folio_size() and then subtract off each piece as we either zero it
or the I/O completes.

I have a bunch of other pagecache / fs work queued up for this cycle, so
I wasn't planning on leaping back into this.  But it's worth making sure
hat people know about one of the problems we figured out three years ago:
https://lore.kernel.org/linux-fsdevel/20200505190825.GB5694@magnolia/