[dm-devel] [PATCH 4/9] multipath-tools: add NetApp E-Series NVMe to hardware table

[Martin Wilck]

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