Re: iomap_dio_rw ->end_io improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019/09/04 7:16, Darrick J. Wong wrote:
> 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.

For zonefs, the changes are not that big (thanks for sending them :)) and
testing does not take long given the lower amount of functionalities compared to
a regular FS. So regression testing with changes to iomap will not be a huge
problem for me. I can do it if needed.

> 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...

No strong opinion either way. I will adjust to what you decide.

> 
> Once iomap accumulates more users (ext4, btrfs) then this sort of thing
> will never scale and will likely never happen again.
> 
> Thoughts?  Flames? :)
> 
> --D
> 


-- 
Damien Le Moal
Western Digital Research




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux