On 11/13/18 5:18 PM, Keith Busch wrote:
On Mon, Nov 12, 2018 at 04:53:23PM -0500, Mike Snitzer wrote:
On Mon, Nov 12 2018 at 11:23am -0500,
Martin Wilck <mwilck@xxxxxxxx> wrote:
Hello Lijie,
On Thu, 2018-11-08 at 14:09 +0800, lijie wrote:
Add support for Asynchronous Namespace Access as specified in NVMe
1.3
TP 4004. The states are updated through reading the ANA log page.
By default, the native nvme multipath takes over the nvme device.
We can pass a false to the parameter 'multipath' of the nvme-core.ko
module,when we want to use multipath-tools.
Thank you for the patch. It looks quite good to me. I've tested it with
a Linux target and found no problems so far.
I have a few questions and comments inline below.
I suggest you also have a look at detect_prio(); it seems to make sense
to use the ana prioritizer for NVMe paths automatically if ANA is
supported (with your patch, "detect_prio no" and "prio ana" have to be
configured explicitly). But that can be done in a later patch.
I (and others) think it makes sense to at least triple check with the
NVMe developers (now cc'd) to see if we could get agreement on the nvme
driver providing the ANA state via sysfs (when modparam
nvme_core.multipath=N is set), like Hannes proposed here:
http://lists.infradead.org/pipermail/linux-nvme/2018-November/020765.html
Then the userspace multipath-tools ANA support could just read sysfs
rather than reinvent harvesting the ANA state via ioctl.
I'd prefer not duplicating the log page parsing. Maybe nvme's shouldn't
even be tied to CONFIG_NVME_MULTIPATH so that the 'multipath' param
isn't even an issue.
My argument here is that _ANA_ support should not be tied to the NVME
native multipathing at all.
Whether or not ANA is present is a choice of the target implementation;
the host has _zero_ influence on this. It may argue all it wants and
doesn't even have to implement multipathing. But in the end if the
target declares a path as 'inaccessible' the path _is_ inaccessible to
the host. Even it that particular host doesn't implement or activate
multipathing.
(You wouldn't believe how often I had this discussion with our QA team
for ALUA ...)
Whether or not _multipathing_ is used is a _host_ implementation, and is
actually independent on ANA support; linux itself proved the point here
as we supported (symmetric) multipathing far longer than we had an ANA
implementation.
So personally I don't see why the 'raw' ANA support (parsing log pages,
figuring out path states etc) needs to be tied in with native NVMe
multipathing. _Especially_ not as my patch really is trivial.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
