From: Laurence Oberman <loberman@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>, Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>,
linux-nvme@lists.infradead.org,
Keith Busch <keith.busch@intel.com>,
Sagi Grimberg <sagi@grimberg.me>,
axboe@kernel.dk, Martin Wilck <mwilck@suse.com>,
lijie <lijie34@huawei.com>,
xose.vazquez@gmail.com, chengjike.cheng@huawei.com,
shenhong09@huawei.com, dm-devel@redhat.com,
wangzhoumengjian@huawei.com, christophe.varoqui@opensvc.com,
bmarzins@redhat.com, sschremm@netapp.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: nvme: allow ANA support to be independent of native multipathing
Date: Fri, 16 Nov 2018 14:34:26 -0500 [thread overview]
Message-ID: <1542396866.13202.0.camel@redhat.com> (raw)
In-Reply-To: <20181116192802.GA30057@redhat.com>
On Fri, 2018-11-16 at 14:28 -0500, Mike Snitzer wrote:
> On Fri, Nov 16 2018 at 5:17am -0500,
> Christoph Hellwig <hch@lst.de> wrote:
>
> > On Fri, Nov 16, 2018 at 11:06:32AM +0100, Hannes Reinecke wrote:
> > > Ok, so would you be happy with making ANA support configurable?
> >
> > I've looked a bit over the whole situation, and what I think we
> > need
> > to do is:
> >
> > a) warn if we see a ANA capable device without multipath support
> > so people know it is not going to work properly.
>
> I disagree with your cynicism but v2 of this patch now emits a
> warning
> accordingly.
>
> > b) deprecate the multipath module option. It was only intended as
> > a migration for any pre-existing PCIe multipath user if there
> > were any, not to support any new functionality. So for 4.20
> > put in a patch that prints a clear warning when it is used,
> > including a link to the nvme list, and then for 4.25 or so
> > remove it entirely unless something unexpected come up.
>
> You rejected the idea of allowing fine-grained control over whether
> native NVMe multipathing is enabled or not on a per-namespace basis.
> All we have is the coarse-grained nvme_core.multipath=N knob. Now
> you're forecasting removing even that. Please don't do that.
>
> > This whole drama of optional multipath use has wasted way too much
> > of everyones time already.
>
> It has wasted _way_ too much time.
>
> But the drama is born out of you rejecting that we need to preserve
> multipath-tools and dm-multipath's ability to work across any
> transport. You don't need to do that work: Hannes, myself and others
> have always been willing and able -- if you'd let us.
>
> IIRC it was at 2016's LSF in Boston where Ewan Milne and I had a
> face-to-face conversation with you in the hallway track where you
> agreed
> that ANA support would be activated if the capability was advertised
> by
> the target. The model we discussed is that it would be comparable to
> how ALUA gets enabled during SCSI LUN discovery.
>
> I hope you can see your way forward to be more accommodating now.
> Especially given the proposed changes are backed by NVMe standards.
>
> Please, PLEASE take v2 of this patch.. please? ;)
>
> Thanks,
> Mike
I am begging you take it too please
Thanks
Laurence
next prev parent reply other threads:[~2018-11-16 19:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1541657381-7452-1-git-send-email-lijie34@huawei.com>
[not found] ` <2691abf6733f791fb16b86d96446440e4aaff99f.camel@suse.com>
[not found] ` <20181112215323.GA7983@redhat.com>
[not found] ` <20181113161838.GC9827@localhost.localdomain>
2018-11-13 18:00 ` multipath-tools: add ANA support for NVMe device Mike Snitzer
2018-11-14 5:38 ` Mike Snitzer
2018-11-14 7:49 ` Hannes Reinecke
2018-11-14 10:36 ` [dm-devel] " Martin Wilck
2018-11-14 17:47 ` Mike Snitzer
2018-11-14 18:51 ` Hannes Reinecke
2018-11-14 19:26 ` Mike Snitzer
2018-11-15 17:46 ` [PATCH] nvme: allow ANA support to be independent of native multipathing Mike Snitzer
2018-11-16 7:25 ` Hannes Reinecke
2018-11-16 14:01 ` Mike Snitzer
2018-11-16 9:14 ` [PATCH] " Christoph Hellwig
2018-11-16 9:40 ` Hannes Reinecke
2018-11-16 9:49 ` Christoph Hellwig
2018-11-16 10:06 ` Hannes Reinecke
2018-11-16 10:17 ` Christoph Hellwig
2018-11-16 19:28 ` Mike Snitzer
2018-11-16 19:34 ` Laurence Oberman [this message]
2018-11-19 9:39 ` Christoph Hellwig
2018-11-19 14:56 ` Mike Snitzer
2018-11-20 9:42 ` Christoph Hellwig
2018-11-20 13:37 ` Mike Snitzer
2018-11-20 16:23 ` Christoph Hellwig
2018-11-16 14:12 ` Mike Snitzer
2018-11-16 18:59 ` [PATCH v2] " Mike Snitzer
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=1542396866.13202.0.camel@redhat.com \
--to=loberman@redhat.com \
--cc=axboe@kernel.dk \
--cc=bmarzins@redhat.com \
--cc=chengjike.cheng@huawei.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=keith.busch@intel.com \
--cc=lijie34@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mwilck@suse.com \
--cc=sagi@grimberg.me \
--cc=shenhong09@huawei.com \
--cc=snitzer@redhat.com \
--cc=sschremm@netapp.com \
--cc=wangzhoumengjian@huawei.com \
--cc=xose.vazquez@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).