[dm-devel] [PATCH 1/9] multipath-tools: fix misspellings

[dm-devel] [PATCH 1/9] multipath-tools: fix misspellings

[Xose Vazquez Perez]

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>
---
 README.md                       | 2 +-
 libmultipath/checkers/rdac.c    | 2 +-
 libmultipath/prioritizers/iet.c | 2 +-
 multipath/multipath.conf.5      | 2 +-
 tests/directio.c                | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index d67888d9..f06f8cea 100644
--- a/README.md
+++ b/README.md
@@ -80,7 +80,7 @@ The following variables can be passed to the `make` command line:
 	The default is `/etc/multipath/conf.d`.
  * `ENABLE_LIBDMMP=0`: disable building libdmmp
  * `ENABLE_DMEVENTS_POLL=0`: disable support for the device-mapper event
-   polling API. For use with pre-5.0 kernels that don't supprt dmevent polling
+   polling API. For use with pre-5.0 kernels that don't support dmevent polling
    (but even if you don't use this option, multipath-tools will work with
    these kernels).
  * `SCSI_DH_MODULES_PRELOAD="(list)"`: specify a space-separated list of SCSI
diff --git a/libmultipath/checkers/rdac.c b/libmultipath/checkers/rdac.c
index d924a9f7..f7aaa30a 100644
--- a/libmultipath/checkers/rdac.c
+++ b/libmultipath/checkers/rdac.c
@@ -96,7 +96,7 @@ int libcheck_init (struct checker * c)
 		goto out;
 	}
 
-	/* get the changeble values */
+	/* get the changeable values */
 	cmd[2] = 0xA + (CHANGEABLE_PAGE_CODE_VALUES << 6);
 	io_hdr.dxferp = &changeable;
 	memset(&changeable, 0, sizeof(struct control_mode_page));
diff --git a/libmultipath/prioritizers/iet.c b/libmultipath/prioritizers/iet.c
index e98773cf..167a46b0 100644
--- a/libmultipath/prioritizers/iet.c
+++ b/libmultipath/prioritizers/iet.c
@@ -31,7 +31,7 @@
 // name: find_regex
 // @param string: string you want to search into
 // @param regex: the pattern used
-// @return result: string finded in string with regex, "none" if none
+// @return result: string found in string with regex, "none" if none
 char *find_regex(char * string, char * regex)
 {
 	int err;
diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
index fe838e38..d57c810b 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -1759,7 +1759,7 @@ The protocol string of the path device. The possible values are \fIscsi:fcp\fR,
 \fIscsi:spi\fR, \fIscsi:ssa\fR, \fIscsi:sbp\fR, \fIscsi:srp\fR,
 \fIscsi:iscsi\fR, \fIscsi:sas\fR, \fIscsi:adt\fR, \fIscsi:ata\fR,
 \fIscsi:unspec\fR, \fIccw\fR, \fIcciss\fR, \fInvme\fR, and \fIundef\fR. This is
-\fBnot\fR a regular expression. the path device protcol string must match
+\fBnot\fR a regular expression. the path device protocol string must match
 exactly. The protocol that a path is using can be viewed by running
 \fBmultipathd show paths format "%d %P"\fR
 .LP
diff --git a/tests/directio.c b/tests/directio.c
index 9f7d3883..20ccc47a 100644
--- a/tests/directio.c
+++ b/tests/directio.c
@@ -693,7 +693,7 @@ static void test_check_state_blksize(void **state)
 	do_libcheck_reset(1);
 }
 
-/* test async checkers pending and getting resovled by another checker
+/* test async checkers pending and getting resolved by another checker
  * as well as the loops for getting multiple events */
 static void test_check_state_async(void **state)
 {
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 2/9] multipath-tools: add HPE Alletra 9000 NVMe to hardware table

[Xose Vazquez Perez]

Info from (page 53, website sometimes is broken):
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00115289en_us or
https://support.hpe.com/hpesc/public/docDisplay?docId=sd00001334en_us&page=GUID-551FCC2F-D8EA-405B-B9DC-2E66C2AE8608.html

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 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index 0f0795c3..b6ff1107 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -119,6 +119,13 @@ static struct hwentry default_hw[] = {
 		.dev_loss      = MAX_DEV_LOSS_TMO,
 		.vpd_vendor_id = VPD_VP_HP3PAR,
 	},
+	{
+		/* Alletra 9000 NVMe */
+		.vendor        = "NVME",
+		.product       = "HPE Alletra",
+		.pgpolicy      = MULTIBUS,
+		.no_path_retry = NO_PATH_RETRY_QUEUE,
+	},
 	{
 		/* RA8000 / ESA12000 */
 		.vendor        = "DEC",
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 3/9] multipath-tools: delete redundant ONTAP NVMe comment

[Xose Vazquez Perez]

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 | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index b6ff1107..814e727a 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -839,11 +839,7 @@ static struct hwentry default_hw[] = {
 		.no_path_retry = 24,
 	},
 	{
-		/*
-		 * NVMe-FC namespace devices: MULTIBUS, queueing preferred
-		 *
-		 * The hwtable is searched backwards, so place this after "Generic NVMe"
-		 */
+		/* ONTAP NVMe */
 		.vendor        = "NVME",
 		.product       = "^NetApp ONTAP Controller",
 		.pgpolicy      = MULTIBUS,
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

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

[Xose Vazquez Perez]

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(+)

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

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 5/9] multipath-tools: add Huawei OceanStor NVMe to hardware table

[Xose Vazquez Perez]

Info from (config removed in latest edition):
https://download.huawei.com/edownload/e/download.do?actionFlag=download&nid=EDOC1100154490&partNo=6001&mid=SUPE_DOC&_t=1612885603000
Old version (page 61-62): https://drive.google.com/file/d/1c5RK4GXX7ofZBFxTtZ_IN1qHyIjw5eR1

Cc: Zhouweigang (Jack) <zhouweigang09@huawei.com>
Cc: Zou Ming <zouming.zouming@huawei.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 | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index 61a5aa16..e5adc2a3 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -1106,6 +1106,14 @@ static struct hwentry default_hw[] = {
 		.pgfailback    = -FAILBACK_IMMEDIATE,
 		.no_path_retry = 15,
 	},
+	{
+		/* OceanStor NVMe */
+		.vendor        = "NVME",
+		.product       = "Huawei-XSG1",
+		.pgpolicy      = MULTIBUS,
+		.checker_name  = DIRECTIO,
+		.no_path_retry = 12,
+	},
 	/*
 	 * Kove
 	 */
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 6/9] multipath-tools: add IBM FlashSystem(TMS RamSan) NVMe to hardware table

[Xose Vazquez Perez]

Info from:
https://www.ibm.com/docs/en/flashsystem-900/1.6.1?topic=configurations-multipathing-information-linux

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 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index e5adc2a3..f825f6d3 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -733,6 +733,13 @@ static struct hwentry default_hw[] = {
 		.product       = "(RamSan|FlashSystem)",
 		.pgpolicy      = MULTIBUS,
 	},
+	{
+		/* FlashSystem(RamSan) NVMe */
+		.vendor        = "NVMe",
+		.product       = "FlashSystem",
+		.pgpolicy      = MULTIBUS,
+		.no_path_retry = NO_PATH_RETRY_FAIL,
+	},
 	{
 		/* (DDN) DCS9900, SONAS 2851-DR1 */
 		.vendor        = "IBM",
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 7/9] multipath-tools: add IBM FlashSystem(Storwize/SVC) NVMe to hardware table

[Xose Vazquez Perez]

Info from:
https://www.ibm.com/docs/en/flashsystem-7x00/8.5.x?topic=system-multipath-configuration-fc-nvme-hosts

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 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index f825f6d3..f99e2537 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -680,6 +680,13 @@ static struct hwentry default_hw[] = {
 		.pgfailback    = -FAILBACK_IMMEDIATE,
 		.prio_name     = PRIO_ALUA,
 	},
+	{
+		/* FlashSystem(Storwize/SVC) NVMe */
+		.vendor        = "NVME",
+		.product       = "IBM[ ]+2145",
+		.pgpolicy      = MULTIBUS,
+		.no_path_retry = NO_PATH_RETRY_QUEUE,
+	},
 	{
 		/* PAV DASD ECKD */
 		.vendor        = "IBM",
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 8/9] multipath-tools: add Pure FlashArray NVMe to hardware table

[Xose Vazquez Perez]

Cc: Uday Shankar <ushankar@purestorage.com>
Cc: Brian Bunker <brian@purestorage.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 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index f99e2537..bef1c8e5 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -1107,6 +1107,13 @@ static struct hwentry default_hw[] = {
 		.fast_io_fail  = 10,
 		.max_sectors_kb = 4096,
 	},
+	{
+		/* FlashArray NVMe */
+		.vendor        = "NVME",
+		.product       = "Pure Storage FlashArray",
+		.pgpolicy      = MULTIBUS,
+		.no_path_retry = 10,
+	},
 	/*
 	 * Huawei
 	 */
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH 9/9] multipath-tools: add Dell EMC PowerStore NVMe to hardware table

[Xose Vazquez Perez]

Info from (page 46):
https://dl.dell.com/content/manual37523884-dell-emc-powerstore-host-configuration-guide.pdf

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 bef1c8e5..47ea5d3d 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -403,6 +403,15 @@ static struct hwentry default_hw[] = {
 		.no_path_retry = 3,
 		.fast_io_fail  = 15,
 	},
+	{
+		/* PowerStore NVMe */
+		.vendor        = ".*",
+		.product       = "dellemc-powerstore",
+		.pgpolicy      = GROUP_BY_PRIO,
+		.prio_name     = PRIO_ANA,
+		.pgfailback    = -FAILBACK_IMMEDIATE,
+		.no_path_retry = 3,
+	},
 	{
 		/* PowerVault ME 4/5 families */
 		.vendor        = "DellEMC",
-- 
2.36.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

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

[Schremmer, Steven]

> 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

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

[Martin Wilck]

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

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

[Schremmer, Steven]

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

Re: [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


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

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

[Schremmer, Steven]

> 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

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

[Martin Wilck]

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

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

[Benjamin Marzinski]

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

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

[Xose Vazquez Perez]

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

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

[Martin Wilck]

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

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

[Xose Vazquez Perez]

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

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

[Martin Wilck]

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