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