Re: [PATCH v4 0/6] iomap: lift the xfs writepage code into iomap

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Sun, Sep 01, 2019 at 12:34:40AM -0700, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 06:46:33PM -0700, Darrick J. Wong wrote:
> > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote:
> > > Darrick,
> > > 
> > > are you going to queue this up?
> > 
> > Yes, I'll go promote the iomap writeback branch to iomap-for-next.  I
> > haven't 100% convinced myself that it's a good idea to hook up xfs to it
> > yet, if nothing else because of all the other problems I've had getting
> > 5.3 testing to run to completion reliably...
> 
> So what is the current status?  We are going to get an -rc8 to give
> you some more time, and I'd really hate to miss the second merge window
> for the change, espececially as things tend to get out of sync, and I
> have various bits touching the code planned for the 5.5 merge window.

Heh, I had assumed today was going to be 5.3 final and that would be
that for 5.4.  However, if the 5.4 merge window isn't going to close
until Sept. 29 then there's still time for more soaking.

Would you mind rebasing the remaining patches against iomap-for-next and
sending that out?  I'll try to get to it before I go on vacation 6 - 15
Sept.

Admittedly I think the controversial questions are still "How much
writeback code are we outsourcing to iomap anyway?" and "Do we want to
do the added stress of keeping that going without breaking everyone
else"?  IOWs, more philosophical than just the mechanics of porting code
around.

I still want a CONFIG_IOMAP_DEBUG which turns on stricter checking of
the iomap(s) that ->begin_iomap pass to the actor, if you have the time;
I for one am starting to forget exactly what are the valid combinations
of iomap flag inputs that ->begin_iomap has to handle for a given actor
and what are the valid imaps for each actor that it can pass back.  :)

--D