> From: Martin Wilck <mwilck@xxxxxxxx> > Sent: Thursday, May 19, 2022 9:47 AM > 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 > Martin, Sorry for being slow to respond to this. NetApp publishes settings for multipath-tools for NVMe-attach E-Series for specific distribution versions that we have qualified. Anyone using these settings outside of these versions would NOT be in a valid system configuration for NetApp support. Are reasonable defaults in the hardware table really useful if they cause a user to follow a path that leads them to an unsupported system configuration? Thanks, Steve -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
