diff for duplicates of <1542396866.13202.0.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 4f31cf8..9b27700 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,32 +1,32 @@ -On Fri, 2018-11-16 at 14:28 -0500, Mike Snitzer wrote: -> On Fri, Nov 16 2018 at 5:17am -0500, +On Fri, 2018-11-16@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: +> > 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. +> > ?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. +> > ?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. +> 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. @@ -35,7 +35,7 @@ On Fri, 2018-11-16 at 14:28 -0500, Mike Snitzer wrote: > > 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 +> 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 @@ -43,7 +43,7 @@ On Fri, 2018-11-16 at 14:28 -0500, Mike Snitzer wrote: > 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 +> 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. diff --git a/a/content_digest b/N1/content_digest index c3dee51..a840127 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,59 +9,40 @@ "ref\0bbaf4637-209c-5cfe-2749-3fcc54f7a35f@suse.de\0" "ref\020181116101752.GA21531@lst.de\0" "ref\020181116192802.GA30057@redhat.com\0" - "From\0Laurence Oberman <loberman@redhat.com>\0" - "Subject\0Re: nvme: allow ANA support to be independent of native multipathing\0" + "From\0loberman@redhat.com (Laurence Oberman)\0" + "Subject\0nvme: allow ANA support to be independent of native multipathing\0" "Date\0Fri, 16 Nov 2018 14:34:26 -0500\0" - "To\0Mike Snitzer <snitzer@redhat.com>" - " Christoph Hellwig <hch@lst.de>\0" - "Cc\0Hannes 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\0" "\00:1\0" "b\0" - "On Fri, 2018-11-16 at 14:28 -0500, Mike Snitzer wrote:\n" - "> On Fri, Nov 16 2018 at\302\240\302\2405:17am -0500,\n" + "On Fri, 2018-11-16@14:28 -0500, Mike Snitzer wrote:\n" + "> On Fri, Nov 16 2018 at??5:17am -0500,\n" "> Christoph Hellwig <hch@lst.de> wrote:\n" "> \n" - "> > On Fri, Nov 16, 2018 at 11:06:32AM +0100, Hannes Reinecke wrote:\n" + "> > On Fri, Nov 16, 2018@11:06:32AM +0100, Hannes Reinecke wrote:\n" "> > > Ok, so would you be happy with making ANA support configurable?\n" "> > \n" "> > I've looked a bit over the whole situation, and what I think we\n" "> > need\n" "> > to do is:\n" "> > \n" - "> > \302\240a) warn if we see a ANA capable device without multipath support\n" - "> > \302\240\302\240\302\240\302\240so people know it is not going to work properly.\n" + "> > ?a) warn if we see a ANA capable device without multipath support\n" + "> > ????so people know it is not going to work properly.\n" "> \n" "> I disagree with your cynicism but v2 of this patch now emits a\n" "> warning\n" "> accordingly.\n" "> \n" - "> > \302\240b) deprecate the multipath module option.\302\240\302\240It was only intended as\n" - "> > \302\240\302\240\302\240\302\240a migration for any pre-existing PCIe multipath user if there\n" - "> > \302\240\302\240\302\240\302\240were any, not to support any new functionality.\302\240\302\240So for 4.20\n" - "> > \302\240\302\240\302\240\302\240put in a patch that prints a clear warning when it is used,\n" - "> > \302\240\302\240\302\240\302\240including a link to the nvme list, and then for 4.25 or so\n" - "> > \302\240\302\240\302\240\302\240remove it entirely unless something unexpected come up.\n" + "> > ?b) deprecate the multipath module option.??It was only intended as\n" + "> > ????a migration for any pre-existing PCIe multipath user if there\n" + "> > ????were any, not to support any new functionality.??So for 4.20\n" + "> > ????put in a patch that prints a clear warning when it is used,\n" + "> > ????including a link to the nvme list, and then for 4.25 or so\n" + "> > ????remove it entirely unless something unexpected come up.\n" "> \n" "> You rejected the idea of allowing fine-grained control over whether\n" "> native NVMe multipathing is enabled or not on a per-namespace basis.\n" - "> All we have is the coarse-grained nvme_core.multipath=N knob.\302\240\302\240Now\n" - "> you're forecasting removing even that.\302\240\302\240Please don't do that.\n" + "> All we have is the coarse-grained nvme_core.multipath=N knob.??Now\n" + "> you're forecasting removing even that.??Please don't do that.\n" "> \n" "> > This whole drama of optional multipath use has wasted way too much\n" "> > of everyones time already.\n" @@ -70,7 +51,7 @@ "> \n" "> But the drama is born out of you rejecting that we need to preserve\n" "> multipath-tools and dm-multipath's ability to work across any\n" - "> transport.\302\240\302\240You don't need to do that work: Hannes, myself and others\n" + "> transport.??You don't need to do that work: Hannes, myself and others\n" "> have always been willing and able -- if you'd let us.\n" "> \n" "> IIRC it was at 2016's LSF in Boston where Ewan Milne and I had a\n" @@ -78,7 +59,7 @@ "> agreed\n" "> that ANA support would be activated if the capability was advertised\n" "> by\n" - "> the target.\302\240\302\240The model we discussed is that it would be comparable to\n" + "> the target.??The model we discussed is that it would be comparable to\n" "> how ALUA gets enabled during SCSI LUN discovery.\n" "> \n" "> I hope you can see your way forward to be more accommodating now.\n" @@ -93,4 +74,4 @@ "Thanks\n" Laurence -e907e9b31ded5d823e4a395018405115e90df109dc6dcd09d7f1428b5ae095df +e688a3c8f00ed4f67eb62713ed2a4e9fd46c5a55e5439eca8a6b55cae8f94d13
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.