[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180529072240.np5c62akbr7jqelr@linux-x5ow.site>
Date: Tue, 29 May 2018 09:22:40 +0200
From: Johannes Thumshirn <jthumshirn@...e.de>
To: Mike Snitzer <snitzer@...hat.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Linux NVMe Mailinglist <linux-nvme@...ts.infradead.org>,
Laurence Oberman <loberman@...hat.com>,
Sagi Grimberg <sagi@...mberg.me>,
James Smart <james.smart@...adcom.com>,
Ewan Milne <emilne@...hat.com>,
Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
Keith Busch <keith.busch@...el.com>,
Hannes Reinecke <hare@...e.de>,
Martin George <marting@...app.com>,
Christoph Hellwig <hch@....de>,
John Meneghini <John.Meneghini@...app.com>
Subject: Re: [PATCH 0/3] Provide more fine grained control over multipathing
On Mon, May 28, 2018 at 11:02:36PM -0400, Mike Snitzer wrote:
> No, what both Red Hat and SUSE are saying is: cool let's have a go at
> "Plan A" but, in parallel, what harm is there in allowing "Plan B" (dm
> multipath) to be conditionally enabled to coexist with native NVMe
> multipath?
For a "Plan B" we can still use the global knob that's already in
place (even if this reminds me so much about scsi-mq which at least we
haven't turned on in fear of performance regressions).
Let's drop the discussion here, I don't think it leads to something
else than flamewars.
Johannes
--
Johannes Thumshirn Storage
jthumshirn@...e.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Powered by blists - more mailing lists