On Tue, Sep 03, 2019 at 03:03:25PM +0200, Christoph Hellwig wrote: > Hi all, > > this series contains two updates to the end_io handling for the iomap > direct I/O code. The first patch is from Matthew and passes the size and > error separately, and has been taken from his series to convert ext4 to > use iomap for direct I/O. The second one moves the end_io handler into a > separate ops structure. This should help with Goldwyns series to use the > iomap code in btrfs, but as-is already ensures that we don't store a > function pointer in a mutable data structure. The biggest problem with merging these patches (and while we're at it, Goldwyn's patch adding a srcmap parameter to ->iomap_begin) for 5.4 is that they'll break whatever Andreas and Damien have been preparing for gfs2 and zonefs (respectively) based off the iomap-writeback work branch that I created off of 5.3-rc2 a month ago. Digging through the gfs2 and zonefs code, it doesn't look like it would be difficult to adapt them to the changes, but forcing a rebase at this point would (a) poke holes in the idea of creating stable work branches and (b) shoot holes in all the regression testing they've done so far. I do not have the hardware to test either in detail. So the question is: Are all three (xfs/gfs2/zonefs?) downstream users of iomap ok with a rebase a week and a half before the 5.4 merge window opens? I'm still inclined to push all these patches (iomap cow and the directio improvements) into a work branch for 5.5, but if someone wants this for 5.4 badly enough to persuade everyone else to start their testing again, then I could see trying to make this happen (no later than 5pm Pacific on Thursday). Bear in mind I'm on vacation starting Friday and going until the 15th... Once iomap accumulates more users (ext4, btrfs) then this sort of thing will never scale and will likely never happen again. Thoughts? Flames? :) --D
