[dm-devel] multipath-tools: add ANA support for NVMe device

[Mike Snitzer]

On Mon, Nov 12 2018 at 11:23am -0500,
Martin Wilck <mwilck at suse.com> 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.

But if we continue to hit a wall on that type of sharing of the nvme
driver's state then I'm fine with reinventing ANA state inquiry and
tracking like has been proposed here.

Mike

p.s. thanks for your review Martin, we really need to determine the way
forward for full multipath-tools support of NVMe with ANA.