Hi Steve, On Thu, 2022-05-19 at 13:18 +0000, Schremmer, Steven wrote: > Martin W, > > > Steve, > > > > On Wed, 2022-05-18 at 20:24 +0000, Schremmer, Steven wrote: > > > > > > Nak. NetApp E-Series only supports these settings in certain > > > configurations, and we prefer to handle it via our installation > > > documentation. > > > > > > > I don't follow. What harm is done to Netapp if these settings are > > included? People can still follow your documentation, the end > > result > > will be the same... no? > > > > AFAICS, the only setting above that would only be supported in > > certain > > configurations is PRIO_ANA, without which GROUP_BY_PRIO doesn't > > make > > much sense. If the array is configured not to support ANA, this > > configuration would lead to error messages and PRIO_UNDEF for all > > paths, and thus "imply" multibus topology. Not beautiful, but also > > no > > big harm done, IMO. > > > > If it's that you're concerned about, please provide the set of > > defaults > > you prefer for E-Series, or explictly state that you prefer to run > > with > > the generic NVMe defaults (const prio, failover policy). > > > > In general, if vendor-recommended settings are strongly dependent > > on > > storage configuration, host-side software defaults must try to > > match > > the storage array's defaults. We shoud do this for E-Series, too. > > If > > ANA needs to be explicitly enabled on the array by the admin, we > > shouldn't enable it by default; but otherwise, we should. > > > > Martin > > NVMe-attached E-Series is moving towards only using the native NVMe > multipathing in the kernel rather than DM-MP with NVMe. At some point > we will stop interoperability testing with NVMe DM-MP and not certify > new > solutions with it. > > The set of defaults listed for NVMe E-Series are the correct ones, > but I'm not sure > they should be included if we aren't going to continue to test the > interoperability > of NVMe-attached E-Series and DM-MP. Thanks for the explanation. I believe everyone understands that the fact that the built-in hwtable in multipath-tools contains sensible defaults for a given storage array does *not* imply that this array has been tested or officially released by Netapp (or any storage vendor). If you want, we can add a statement of this kind (vendor-neutral) to our man page and/or README. It's also understood that Netapp, like the kernel community, recommends native multipathing for NVMe, and discourages use of device-mapper multipath for NVMe devices. Native multipathing is the kernel default, and must be explicitly disabled either at build time or on the kernel command line before dm-multipath would even see the devices. IMO it can be assumed that a user who employs such a setup knows what she's doing, and is aware that the setup doesn't comply with common recommendations. Netapp currently publishes configuration recommendations for multipath- tools with E-Series and NVMe. Xose's patch simply changes the built-in defaults to match these recommendations. We have been doing this for years with the intention to improve the "out of the box" experience, and it's a good thing. If we didn't take this patch, we'd knowingly force suboptimal default settings on (admittedly few) users. Who would benefit from that? We want to ship multipath-tools with the most reasonable defaults that we are aware of. Xose's continued efforts in this area have been immensely useful for the community of dm-multipath users. I don't think we should give this up. I'd like to encourage everyone to continue submitting improvements for the hardware table. Regards, Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
