Message ID | 20220514230148.139675-5-xose.vazquez@gmail.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Delegated to: | christophe varoqui |
Headers | show |
Series | [1/9] multipath-tools: fix misspellings | expand |
> From: Xose Vazquez Perez <xose.vazquez@gmail.com> > Cc: NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com> > Cc: Martin Wilck <mwilck@suse.com> > Cc: Benjamin Marzinski <bmarzins@redhat.com> > Cc: Christophe Varoqui <christophe.varoqui@opensvc.com> > Cc: DM-DEVEL ML <dm-devel@redhat.com> > Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> > --- > libmultipath/hwtable.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c > index 814e727a..61a5aa16 100644 > --- a/libmultipath/hwtable.c > +++ b/libmultipath/hwtable.c > @@ -845,6 +845,15 @@ static struct hwentry default_hw[] = { > .pgpolicy = MULTIBUS, > .no_path_retry = NO_PATH_RETRY_QUEUE, > }, > + { > + /* E-Series NVMe */ > + .vendor = "NVME", > + .product = "NetApp E-Series", > + .pgpolicy = GROUP_BY_PRIO, > + .prio_name = PRIO_ANA, > + .pgfailback = -FAILBACK_IMMEDIATE, > + .no_path_retry = 30, > + }, > /* > * NEC > */ > -- > 2.36.1 Nak. NetApp E-Series only supports these settings in certain configurations, and we prefer to handle it via our installation documentation. Thanks, Steve -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Steve, On Wed, 2022-05-18 at 20:24 +0000, Schremmer, Steven wrote: > > From: Xose Vazquez Perez <xose.vazquez@gmail.com> > > Cc: NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com> > > Cc: Martin Wilck <mwilck@suse.com> > > Cc: Benjamin Marzinski <bmarzins@redhat.com> > > Cc: Christophe Varoqui <christophe.varoqui@opensvc.com> > > Cc: DM-DEVEL ML <dm-devel@redhat.com> > > Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> > > --- > > libmultipath/hwtable.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c > > index 814e727a..61a5aa16 100644 > > --- a/libmultipath/hwtable.c > > +++ b/libmultipath/hwtable.c > > @@ -845,6 +845,15 @@ static struct hwentry default_hw[] = { > > .pgpolicy = MULTIBUS, > > .no_path_retry = NO_PATH_RETRY_QUEUE, > > }, > > + { > > + /* E-Series NVMe */ > > + .vendor = "NVME", > > + .product = "NetApp E-Series", > > + .pgpolicy = GROUP_BY_PRIO, > > + .prio_name = PRIO_ANA, > > + .pgfailback = -FAILBACK_IMMEDIATE, > > + .no_path_retry = 30, > > + }, > > /* > > * NEC > > */ > > -- > > 2.36.1 > > 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 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
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, Steve -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
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@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
> From: Martin Wilck <mwilck@suse.com> > 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@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Hi Steve, On Thu, 2022-05-26 at 20:10 +0000, Schremmer, Steven wrote: > > From: Martin Wilck <mwilck@suse.com> > > 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. Anyone using wrong or suboptimal settings on an unsupported distribution would also NOT be a valid configuration for NetApp support, right? But they'd be more likely to call 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? Do you have any evidence that such an hardware table entry would "cause" users to follow this path? I have to say it sounds far-fetched to me. People who buy NetApp storage should have evaluated the system requirements and support restrictions beforehand. If they decide to use an unsupported distribution nonetheless, they will have strong reasons, and won't be deterred by wrong defaults in multipath-tools. Rather, they'll look up the settings in your manuals and configure them manually. If they call NetApp support, support engineers can still ask them to reproduce their issue in a supported environment. AFAIU, NetApp doesn't support using upstream multipath-tools at all. Should we consequently just drop all settings for NetApp storage and OEMs from the upstream code base? You're certainly aware that distros like RHEL or SLES get their default settings through upstream, which is a good thing. Without good upstream defaults, users of these distros would need to enter the settings manually in multipath.conf rather than having reasonable settings applied out of the box. That'd be a serious deterioration of the user experience. Regards Martin PS: Every Linux user understands that "it works" and "it's supported by the hardware vendor" are two _very_ different things, simply because there are so few vendors that support Linux at all. I don't think I ever had a laptop running an officially supported OS. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, May 31, 2022 at 10:43:01AM +0200, Martin Wilck wrote: > Hi Steve, > > On Thu, 2022-05-26 at 20:10 +0000, Schremmer, Steven wrote: > > > From: Martin Wilck <mwilck@suse.com> > > > 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. > > Anyone using wrong or suboptimal settings on an unsupported > distribution would also NOT be a valid configuration for NetApp > support, right? But they'd be more likely to call 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? > > Do you have any evidence that such an hardware table entry would > "cause" users to follow this path? I have to say it sounds far-fetched > to me. People who buy NetApp storage should have evaluated the system > requirements and support restrictions beforehand. If they decide to use > an unsupported distribution nonetheless, they will have strong reasons, > and won't be deterred by wrong defaults in multipath-tools. Rather, > they'll look up the settings in your manuals and configure them > manually. If they call NetApp support, support engineers can still ask > them to reproduce their issue in a supported environment. > > AFAIU, NetApp doesn't support using upstream multipath-tools at all. > Should we consequently just drop all settings for NetApp storage and > OEMs from the upstream code base? You're certainly aware that distros > like RHEL or SLES get their default settings through upstream, which is > a good thing. Without good upstream defaults, users of these distros > would need to enter the settings manually in multipath.conf rather than > having reasonable settings applied out of the box. That'd be a serious > deterioration of the user experience. With RHEL-9 and going forward, RHEL is recommending and defaulting to using native multipathing for NVMe devices over dm-multipathing. That means that people who use dm-multipath for these devices will already actively be making the decision to not use the recommended settings. We don't make any claims that the multipath.conf defaults have any official support. We have always included default configs that have no official blessing from their vendors. The goal is to give the average user a good starting point for configuring their system. If you do have an official recommened dm-multipath configuration, we will certainly use that. But if there simply isn't any recommended config because you don't recommend that people use dm-multipath, then I don't see the harm in providing "reasonable defaults" (as the multipath.conf man page calls them) to the users that make the choice to use dm-multipath for NVMe devices. - Ben > Regards > Martin > > PS: Every Linux user understands that "it works" and "it's supported by > the hardware vendor" are two _very_ different things, simply because > there are so few vendors that support Linux at all. I don't think I > ever had a laptop running an officially supported OS. > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On 5/26/22 22:10, Schremmer, Steven wrote: > 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? Do you(@NetApp crew) realize that the "NVME/.*" prod/vendor was added more than five years ago: https://github.com/opensvc/multipath-tools/commit/4dd25783e13909cba0c38ed8bfedf76dc5a38c7b#diff-eeab98c4bb0459858e2ad17c9aa77ea30ee7a900e16cddb5325b9984b1694021 Your argument doesn't make any sense. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Xose, On Thu, 2022-06-09 at 18:36 +0200, Xose Vazquez Perez wrote: > On 5/26/22 22:10, Schremmer, Steven wrote: > > > 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? > > Do you(@NetApp crew) realize that the "NVME/.*" prod/vendor was added > more than five years ago: > https://github.com/opensvc/multipath-tools/commit/4dd25783e13909cba0c38ed8bfedf76dc5a38c7b#diff-eeab98c4bb0459858e2ad17c9aa77ea30ee7a900e16cddb5325b9984b1694021 > > Your argument doesn't make any sense. IIUC NetApp's concern is not the generic entry, but the entries mentioning E-Series or it's OEM products in NVMe configuration explicitly. I also have some trouble understanding the concern, but NetApp is in charge of these entries, so I believe we should respect what they're saying. With the late patches I submitted, the generic NVMe defaults would work for the NetApp devices without those being explicitly mentioned. I hope this is ok for everyone. Only the no_path_retry setting would get lost, which is acceptable IMO because this is rather an admin setting than product-specific. Regards Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On 6/9/22 18:49, Martin Wilck wrote: > IIUC NetApp's concern is not the generic entry, but the entries > mentioning E-Series or it's OEM products in NVMe configuration > explicitly. I also have some trouble understanding the concern, but > NetApp is in charge of these entries, so I believe we should respect > what they're saying. > > With the late patches I submitted, the generic NVMe defaults would work > for the NetApp devices without those being explicitly mentioned. I hope > this is ok for everyone. Only the no_path_retry setting would get lost, > which is acceptable IMO because this is rather an admin setting than > product-specific. And now (IMO) it is worse, because NetApp NVMe arrays are under a generic config. What do they hate? just ".product = "NetApp E-Series"" ??? -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Thu, 2022-06-09 at 18:56 +0200, Xose Vazquez Perez wrote: > On 6/9/22 18:49, Martin Wilck wrote: > > > IIUC NetApp's concern is not the generic entry, but the entries > > mentioning E-Series or it's OEM products in NVMe configuration > > explicitly. I also have some trouble understanding the concern, but > > NetApp is in charge of these entries, so I believe we should > > respect > > what they're saying. > > > > With the late patches I submitted, the generic NVMe defaults would > > work > > for the NetApp devices without those being explicitly mentioned. I > > hope > > this is ok for everyone. Only the no_path_retry setting would get > > lost, > > which is acceptable IMO because this is rather an admin setting > > than > > product-specific. > > And now (IMO) it is worse, because NetApp NVMe arrays are under a > generic config. > > What do they hate? just ".product = "NetApp E-Series"" ??? I can't speak for Steve, but yes, this is what I understood. The concern is that someone would read the entry and conclude that this configuration is officially endorsed and supported by NetApp. This is why I added the disclaimer in the man page. Regards, Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c index 814e727a..61a5aa16 100644 --- a/libmultipath/hwtable.c +++ b/libmultipath/hwtable.c @@ -845,6 +845,15 @@ static struct hwentry default_hw[] = { .pgpolicy = MULTIBUS, .no_path_retry = NO_PATH_RETRY_QUEUE, }, + { + /* E-Series NVMe */ + .vendor = "NVME", + .product = "NetApp E-Series", + .pgpolicy = GROUP_BY_PRIO, + .prio_name = PRIO_ANA, + .pgfailback = -FAILBACK_IMMEDIATE, + .no_path_retry = 30, + }, /* * NEC */
Info from (page 12): https://docs.netapp.com/us-en/e-series/pdfs/sidebar/NVMe_over_Fibre_Channel_setup.pdf Cc: NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Benjamin Marzinski <bmarzins@redhat.com> Cc: Christophe Varoqui <christophe.varoqui@opensvc.com> Cc: DM-DEVEL ML <dm-devel@redhat.com> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> --- libmultipath/hwtable.c | 9 +++++++++ 1 file changed, 9 insertions(+)