From: Mike Snitzer <snitzer@redhat.com> To: 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:28:02 -0500 [thread overview] Message-ID: <20181116192802.GA30057@redhat.com> (raw) In-Reply-To: <20181116101752.GA21531@lst.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: snitzer@redhat.com (Mike Snitzer) Subject: nvme: allow ANA support to be independent of native multipathing Date: Fri, 16 Nov 2018 14:28:02 -0500 [thread overview] Message-ID: <20181116192802.GA30057@redhat.com> (raw) In-Reply-To: <20181116101752.GA21531@lst.de> On Fri, Nov 16 2018 at 5:17am -0500, Christoph Hellwig <hch@lst.de> wrote: > On Fri, Nov 16, 2018@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
next prev parent reply other threads:[~2018-11-16 19:28 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-08 6:09 [PATCH] multipath-tools: add ANA support for NVMe device lijie 2018-11-12 16:23 ` Martin Wilck 2018-11-12 21:53 ` Mike Snitzer 2018-11-12 21:53 ` Mike Snitzer 2018-11-13 6:59 ` Martin Wilck 2018-11-13 6:59 ` Martin Wilck 2018-11-13 16:18 ` Keith Busch 2018-11-13 16:18 ` Keith Busch 2018-11-13 18:00 ` Mike Snitzer 2018-11-13 18:00 ` Mike Snitzer 2018-11-14 5:38 ` Mike Snitzer 2018-11-14 5:38 ` Mike Snitzer 2018-11-14 7:49 ` Hannes Reinecke 2018-11-14 7:49 ` Hannes Reinecke 2018-11-14 10:36 ` [dm-devel] " Martin Wilck 2018-11-14 10:36 ` Martin Wilck 2018-11-14 17:47 ` Mike Snitzer 2018-11-14 17:47 ` Mike Snitzer 2018-11-14 18:51 ` Hannes Reinecke 2018-11-14 18:51 ` Hannes Reinecke 2018-11-14 19:26 ` Mike Snitzer 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-15 17:46 ` Mike Snitzer 2018-11-16 7:25 ` Hannes Reinecke 2018-11-16 7:25 ` Hannes Reinecke 2018-11-16 14:01 ` Mike Snitzer 2018-11-16 14:01 ` Mike Snitzer 2018-11-16 9:14 ` [PATCH] " Christoph Hellwig 2018-11-16 9:14 ` Christoph Hellwig 2018-11-16 9:40 ` Hannes Reinecke 2018-11-16 9:40 ` Hannes Reinecke 2018-11-16 9:49 ` Christoph Hellwig 2018-11-16 9:49 ` Christoph Hellwig 2018-11-16 10:06 ` Hannes Reinecke 2018-11-16 10:06 ` Hannes Reinecke 2018-11-16 10:17 ` Christoph Hellwig 2018-11-16 10:17 ` Christoph Hellwig 2018-11-16 19:28 ` Mike Snitzer [this message] 2018-11-16 19:28 ` Mike Snitzer 2018-11-16 19:34 ` Laurence Oberman 2018-11-16 19:34 ` Laurence Oberman 2018-11-19 9:39 ` Christoph Hellwig 2018-11-19 9:39 ` Christoph Hellwig 2018-11-19 14:56 ` Mike Snitzer 2018-11-19 14:56 ` Mike Snitzer 2018-11-19 14:56 ` Mike Snitzer 2018-11-20 9:42 ` Christoph Hellwig 2018-11-20 9:42 ` Christoph Hellwig 2018-11-20 13:37 ` Mike Snitzer 2018-11-20 13:37 ` Mike Snitzer 2018-11-20 16:23 ` Christoph Hellwig 2018-11-20 16:23 ` Christoph Hellwig 2018-11-16 14:12 ` Mike Snitzer 2018-11-16 14:12 ` Mike Snitzer 2018-11-16 18:59 ` [PATCH v2] " Mike Snitzer 2018-11-16 18:59 ` Mike Snitzer 2018-11-14 7:24 ` multipath-tools: add ANA support for NVMe device Hannes Reinecke 2018-11-14 7:24 ` Hannes Reinecke 2018-11-14 15:35 ` Christoph Hellwig 2018-11-14 15:35 ` Christoph Hellwig 2018-11-14 16:16 ` Mike Snitzer 2018-11-14 16:16 ` 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=20181116192802.GA30057@redhat.com \ --to=snitzer@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=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: linkBe 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.