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

From: Matthew Wilcox <willy@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Luis Chamberlain <mcgrof@kernel.org>,
	lsf-pc@lists.linux-foundation.org,
	Christoph Hellwig <hch@infradead.org>,
	David Howells <dhowells@redhat.com>,
	"kbus @imap.suse.de>> Keith Busch" <kbusch@kernel.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: LSF/MM/BPF 2023 IOMAP conversion status update
Date: Mon, 27 Feb 2023 21:02:29 +0000	[thread overview]
Message-ID: <Y/0aZYKvvyinw3b6@casper.infradead.org> (raw)
In-Reply-To: <Y/0D2UYzmhuCigg4@magnolia>

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/