| Message ID | EF473529-CF81-4AE9-BD96-08624B59BA10@purestorage.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | christophe varoqui |
| Headers | show |
| Series | ALUA support for PURE FlashArray | expand |
On 6/26/19 7:37 PM, Brian Bunker wrote: > It has been some time since we updated our PURE FlashArray configuration. The > Linux vendors that we had been seeing in the field were using very old versions > of multipath-tools, so we haven’t needed to change anything for some time. With > the release of RHEL8, some of our earlier values have been lost by upstream > changes. > > In addition we have our Active Cluster feature which leverages ALUA since our > last patch. The ALUA confguration will work for all FlashArrays with or without > Active Cluster. > > We are changing 3 things. > > 1. ALUA support > > 2. Fast fail timeout from the default of 5 seconds to 10 seconds (We need this > for our FC NPIV port migration). > > 3. Maximum sector size of 4MB. Some Linux vendors don’t honor the block limits > VPD page of INQUIRY). #3, kernel or udev bug? > diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c > index 1d964333..37e97f60 100644 > --- a/libmultipath/hwtable.c > +++ b/libmultipath/hwtable.c > @@ -1024,7 +1024,12 @@ static struct hwentry default_hw[] = { > /* FlashArray */ > .vendor = "PURE", > .product = "FlashArray", > - .pgpolicy = MULTIBUS, > + .pgpolicy = GROUP_BY_PRIO, > + .pgfailback = -FAILBACK_IMMEDIATE, > + .hwhandler = "1 alua", > + .prio_name = PRIO_ALUA, > + .fast_io_fail = 10, > + .max_sectors_kb = 4096, -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Xose, I just saw this. Sorry for the late response. I am not sure if the max_sectors_kb is a kernel or udev bug. What I would expect is for the block limits INQUIRY VPD page, 0xB0, to be used to populate the /sys/block entries for max_sectors_kb. We have seen Linux distributions that don’t seem to do that but instead populate that entry with 32 MB even though we return 4 MB as our limit. We add the 4 MB limit in a udev rule that we have created and provide to our customers. Adding it in multipath.conf will also get us 4 MB for the dm device and its slaves which is what we want. I don’t know if there is a preferred way but if we use multipath.conf then hopefully no users will ever have to deal with the higher value that will error out if a SCSI read or write is actually sent larger than the 4 MB maximum size. Thanks, Brian Brian Bunker SW Eng brian@purestorage.com > On Aug 7, 2019, at 9:05 AM, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote: > > On 6/26/19 7:37 PM, Brian Bunker wrote: > >> It has been some time since we updated our PURE FlashArray configuration. The >> Linux vendors that we had been seeing in the field were using very old versions >> of multipath-tools, so we haven’t needed to change anything for some time. With >> the release of RHEL8, some of our earlier values have been lost by upstream >> changes. >> >> In addition we have our Active Cluster feature which leverages ALUA since our >> last patch. The ALUA confguration will work for all FlashArrays with or without >> Active Cluster. >> >> We are changing 3 things. >> >> 1. ALUA support >> >> 2. Fast fail timeout from the default of 5 seconds to 10 seconds (We need this >> for our FC NPIV port migration). >> >> 3. Maximum sector size of 4MB. Some Linux vendors don’t honor the block limits >> VPD page of INQUIRY). > > > #3, kernel or udev bug? > > >> diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c >> index 1d964333..37e97f60 100644 >> --- a/libmultipath/hwtable.c >> +++ b/libmultipath/hwtable.c >> @@ -1024,7 +1024,12 @@ static struct hwentry default_hw[] = { >> /* FlashArray */ >> .vendor = "PURE", >> .product = "FlashArray", >> - .pgpolicy = MULTIBUS, >> + .pgpolicy = GROUP_BY_PRIO, >> + .pgfailback = -FAILBACK_IMMEDIATE, >> + .hwhandler = "1 alua", >> + .prio_name = PRIO_ALUA, >> + .fast_io_fail = 10, >> + .max_sectors_kb = 4096, -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 9/12/19 3:52 AM, Brian Bunker wrote: > I am not sure if the max_sectors_kb is a kernel or udev bug. What I would expect is for the block limits > INQUIRY VPD page, 0xB0, to be used to populate the /sys/block entries for max_sectors_kb. We have > seen Linux distributions that don’t seem to do that but instead populate that entry with 32 MB even though marginal or main distributions? > we return 4 MB as our limit. We add the 4 MB limit in a udev rule that we have created and provide to our > customers. Adding it in multipath.conf will also get us 4 MB for the dm device and its slaves which is what we > want. I don’t know if there is a preferred way but if we use multipath.conf then hopefully no users will ever > have to deal with the higher value that will error out if a SCSI read or write is actually sent larger than > the 4 MB maximum size. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 6/26/19 7:37 PM, Brian Bunker wrote: > It has been some time since we updated our PURE FlashArray configuration. The > Linux vendors that we had been seeing in the field were using very old versions > of multipath-tools, so we haven’t needed to change anything for some time. With > the release of RHEL8, some of our earlier values have been lost by upstream > changes. Resend it, with CC: Christophe Varoqui <christophe.varoqui@opensvc.com> > In addition we have our Active Cluster feature which leverages ALUA since our > last patch. The ALUA confguration will work for all FlashArrays with or without > Active Cluster. > > We are changing 3 things. > > 1. ALUA support > > 2. Fast fail timeout from the default of 5 seconds to 10 seconds (We need this > for our FC NPIV port migration). > > 3. Maximum sector size of 4MB. Some Linux vendors don’t honor the block limits > VPD page of INQUIRY). > > diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c > index 1d964333..37e97f60 100644 > --- a/libmultipath/hwtable.c > +++ b/libmultipath/hwtable.c > @@ -1024,7 +1024,12 @@ static struct hwentry default_hw[] = { > /* FlashArray */ > .vendor = "PURE", > .product = "FlashArray", > - .pgpolicy = MULTIBUS, > + .pgpolicy = GROUP_BY_PRIO, > + .pgfailback = -FAILBACK_IMMEDIATE, > + .hwhandler = "1 alua", > + .prio_name = PRIO_ALUA, > + .fast_io_fail = 10, > + .max_sectors_kb = 4096, -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 10/4/19 10:51 PM, Xose Vazquez Perez wrote: > On 6/26/19 7:37 PM, Brian Bunker wrote: > >> It has been some time since we updated our PURE FlashArray configuration. The >> Linux vendors that we had been seeing in the field were using very old versions >> of multipath-tools, so we haven’t needed to change anything for some time. With >> the release of RHEL8, some of our earlier values have been lost by upstream >> changes. > > Resend it, with CC: Christophe Varoqui <christophe.varoqui@opensvc.com> Could you please also send the conf. for NVMe devices [1] ? Thank you. [1] https://blog.purestorage.com/nvmeof-roce-suse-15/ -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c index 1d964333..37e97f60 100644 --- a/libmultipath/hwtable.c +++ b/libmultipath/hwtable.c @@ -1024,7 +1024,12 @@ static struct hwentry default_hw[] = { /* FlashArray */ .vendor = "PURE", .product = "FlashArray", - .pgpolicy = MULTIBUS, + .pgpolicy = GROUP_BY_PRIO, + .pgfailback = -FAILBACK_IMMEDIATE, + .hwhandler = "1 alua", + .prio_name = PRIO_ALUA, + .fast_io_fail = 10, + .max_sectors_kb = 4096, }, /* * Huawei