[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180529080952.GA1369@lst.de>
Date: Tue, 29 May 2018 10:09:52 +0200
From: Christoph Hellwig <hch@....de>
To: Johannes Thumshirn <jthumshirn@...e.de>
Cc: Mike Snitzer <snitzer@...hat.com>,
"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 Tue, May 29, 2018 at 09:22:40AM +0200, Johannes Thumshirn wrote:
> 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.
If our plan A doesn't work we can go back to these patches. For now
I'd rather have everyone spend their time on making Plan A work then
preparing for contingencies. Nothing prevents anyone from using these
patches already out there if they really want to, but I'd recommend
people are very careful about doing so as you'll lock yourself into
a long-term maintainance burden.
Powered by blists - more mailing lists