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. 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
