[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181119093938.GA11757@lst.de>
Date: Mon, 19 Nov 2018 10:39:38 +0100
From: Christoph Hellwig <hch@....de>
To: Mike Snitzer <snitzer@...hat.com>
Cc: Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
linux-nvme@...ts.infradead.org,
Keith Busch <keith.busch@...el.com>,
Sagi Grimberg <sagi@...mberg.me>, axboe@...nel.dk,
Martin Wilck <mwilck@...e.com>, lijie <lijie34@...wei.com>,
xose.vazquez@...il.com, chengjike.cheng@...wei.com,
shenhong09@...wei.com, dm-devel@...hat.com,
wangzhoumengjian@...wei.com, christophe.varoqui@...nsvc.com,
bmarzins@...hat.com, sschremm@...app.com,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: nvme: allow ANA support to be independent of native
multipathing
On Fri, Nov 16, 2018 at 02:28:02PM -0500, Mike Snitzer wrote:
> 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.
The whole point is that this hook was intended as a band aid for the
hypothetical pre-existing setups. Not ever for new development.
> Please, PLEASE take v2 of this patch.. please? ;)
See the previous mail for the plan ahead. I'm sick and tired of you
trying to sneak your new developemts back in.
Powered by blists - more mailing lists