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@infradead.org>
Cc: xfs <linux-xfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Andreas Gruenbacher <agruenba@redhat.com>
Subject: Re: [ANNOUNCE] xfs-linux: iomap-5.4-merge rebased to 1b4fdf4f30db
Date: Thu, 19 Sep 2019 21:19:32 +0000	[thread overview]
Message-ID: <BYAPR04MB58160BB6899EA306089288C6E7890@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20190919194011.GN2229799@magnolia

On 2019/09/19 21:40, Darrick J. Wong wrote:
> On Thu, Sep 19, 2019 at 10:08:04AM -0700, Christoph Hellwig wrote:
>> On Thu, Sep 19, 2019 at 04:19:37PM +0000, Damien Le Moal wrote:
>>> OK. Will do, but traveling this week so I will not be able to test until next week.
>>
>> Which suggests zonefs won't make it for 5.4, right?  At that point
>> I wonder if we should defer the whole generic iomap writeback thing
>> to 5.5 entirely.  The whole idea of having two copies of the code always
>> scared me, even more so given that 5.4 is slated to be a long term
>> stable release.
>>
>> So maybe just do the trivial typo + end_io cleanups for Linus this
>> merge window?
> 
> I for one don't mind pulling back to just these three patches:
> 
> iomap: Fix trivial typo
> iomap: split size and error for iomap_dio_rw ->end_io
> iomap: move the iomap_dio_rw ->end_io callback into a structure
> 
> But frankly, do we even need the two directio patches?  IIRC Matthew
> Bobrowski wanted them for the ext4 directio port, but seeing as Ted
> isn't submitting that for 5.4 and gfs2 doesn't supply a directio endio
> handler, maybe I should just send the trivial typo fix and that's it?
> 
> I hate playing into this "It's an LTS but Greg won't admit it" BS but
> I'm gonna do it anyway -- for any release that's been declared to be an
> LTS release, we have no business pushing new functionality (especially
> if it isn't going to be used by anyone) at all.  It would have been
> helpful to have had such a declaration as a solid reason to push back
> against riskier additions, like I did for the last couple of LTSes.
> 
> (And since I didn't have such a tool, I was willing to push the
> writeback bits anyway for the sake of zonefs since it would have been
> the only user, but seeing as Linus rejected zonefs for lack of
> discussion, I think that (the directio api change; iomap writeback; and
> zonefs) is just going to have to wait for 5.5.)

From what I understood from Linus comment and discussion last week, it seems to
me like the iomap part only was OK for 5.4, even without zonefs as a user. I
definitely got a clear signal that zonefs will be accepted only after we get
more comments and some time spent in linux-next, meaning that at best it will be
5.5. And frankly, having iomap already merged at that point would make things
easier for me, and also probably for other FSes moving to iomap. So I am in
favor of trying to push the changes into 5.4.

But pushing for changes without a user not being the usual approach, I would
understand this is all delayed to 5.5. If that is the case, I will simply keep
working on zonefs using your branch instead of Linus master.

Thanks !

-- 
Damien Le Moal
Western Digital Research

  parent reply	other threads:[~2019-09-19 21:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 15:37 [ANNOUNCE] xfs-linux: iomap-5.4-merge rebased to 1b4fdf4f30db Darrick J. Wong
2019-09-19 16:19 ` Damien Le Moal
2019-09-19 17:08   ` Christoph Hellwig
2019-09-19 19:40     ` Darrick J. Wong
2019-09-19 21:03       ` Christoph Hellwig
2019-09-19 21:19       ` Damien Le Moal [this message]
2019-09-19 21:28     ` Damien Le Moal

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=BYAPR04MB58160BB6899EA306089288C6E7890@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=agruenba@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.