[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20181120162343.GB2774@lst.de>
Date: Tue, 20 Nov 2018 17:23:43 +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 Tue, Nov 20, 2018 at 08:37:19AM -0500, Mike Snitzer wrote:
> This isn't how a Linux maintainer engages in technical discussion.
And this isn't a technical discussion. As told before the only
reason to not build the multipath code is to save space, and
the only reason to disable multipath at runtime is for potential
pre-existing setups, which obviously are not ANA capable.
The right fix is to warn users if they use a driver without
CONFIG_NVME_MULTIPATH on a multi-port device and to phase out the
multipath=0 option in the long run, again with a warning. Any new
additions to "improve" these cases simply don't make sense.
Powered by blists - more mailing lists