All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	"agruenba@redhat.com" <agruenba@redhat.com>,
	Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>
Subject: Re: iomap_dio_rw ->end_io improvements
Date: Wed, 4 Sep 2019 02:19:19 +0000	[thread overview]
Message-ID: <BN8PR04MB5812B14013BB4CB892F33B20E7B80@BN8PR04MB5812.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20190903221621.GH568270@magnolia

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

  reply	other threads:[~2019-09-04  2:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 13:03 iomap_dio_rw ->end_io improvements Christoph Hellwig
2019-09-03 13:03 ` [PATCH 1/2] iomap: split size and error for iomap_dio_rw ->end_io Christoph Hellwig
2019-09-03 14:44   ` Darrick J. Wong
2019-09-03 15:24   ` Matthew Wilcox
2019-09-03 13:03 ` [PATCH 2/2] iomap: move the iomap_dio_rw ->end_io callback into a structure Christoph Hellwig
2019-09-03 14:46   ` Darrick J. Wong
2019-09-03 16:14   ` Matthew Wilcox
2019-09-04 12:51     ` Christoph Hellwig
2019-09-03 21:32 ` iomap_dio_rw ->end_io improvements Matthew Bobrowski
2019-09-03 22:16 ` Darrick J. Wong
2019-09-04  2:19   ` Damien Le Moal [this message]
2019-09-04  5:12   ` Christoph Hellwig
2019-09-04 11:46     ` Andreas Gruenbacher
2019-09-04 17:45       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN8PR04MB5812B14013BB4CB892F33B20E7B80@BN8PR04MB5812.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=agruenba@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=rgoldwyn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.