On Wed, Nov 14 2018 at 10:35am -0500, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Nov 14, 2018 at 08:24:05AM +0100, Hannes Reinecke wrote: > > My argument here is that _ANA_ support should not be tied to the NVME > > native multipathing at all. > > It should. Because nvme driver multipathing is the only sanctioned > way to use it. All other ways aren't supported and might break at > any time. Quite a few of us who are multipath-tools oriented would like the proper separation rather than your more pragmatic isolated approach. And we'd fix it if it broke in the future. > > 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. > > And not actually usable for anything.. They only thing you do is to > increase the code size for embedded nvme users that don't need any > multipathing. Isn't that why CONFIG_NVME_MULTIPATH exists? Embedded nvme users wouldn't set that. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
