multipath-tools: standardize all RDAC devices
authorXose Vazquez Perez <xose.vazquez@gmail.com>
Wed, 10 Aug 2016 16:20:32 +0000 (18:20 +0200)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Tue, 16 Aug 2016 07:18:53 +0000 (09:18 +0200)
commitc1ed393b91acace284901f16954ba5c1c0d943c9
tree1c03b1fe855a446568f2cf7c7e5c8ec57dac8ec6
parent2a57399e24391552126f416dc8ace858dbe7f978
multipath-tools: standardize all RDAC devices

This is a combo patch.

Reorder keyworks as in code and manpage for "(NETAPP|LSI|ENGENIO)"/"INF-01-00",
and clone its configuration to ALL other RDAC devices.

There are only two differences in all rdac devices. And they look minor:
.features and .no_path_retry

 devices                keyword          values
 =======                ==============   ====================
      3                 .features      = "1 queue_if_no_path",

      5                 .no_path_retry = 15,
      1                 .no_path_retry = 30,
      3                 .no_path_retry = 300,
     10                 .no_path_retry = NO_PATH_RETRY_QUEUE,

"queue_if_no_path" is identical to the "no_path_retry" keyword.
So "queue_if_no_path" can be replaced by "no_path_retry = XX"

And there are just six devices with:
      6                 .features      = "2 pg_init_retries 50",

Sean Stewart, from NetApp, provided more detailed information:

"The pg_init_retries value should be good for all RDAC devices, and can be
synced, the no_path_retry should also be fine. I don’t think that there’s
necessarily an “ideal” value for it, and may be more of a user preference type
of thing, but I personally don’t see anything wrong with having that value on
all RDAC devices, as well. It’s easy enough to change in the conf file if an end
user needs a different value."

I think the pg_init_retries parameter is set as such because part of
scsi_dh_rdac’s path activation involves sending a Mode Select page 0x2C to
change the ownership. If the array is already processing one, it will return
with a vendor unique check condition (05/91/36), which returns SCSI_DH_RETRY."

As for the no_path_retry, we’ve seen scenarios where both paths can be
temporarily unavailable during a storage firmware upgrade, usually because udev
processing has not added the path from one controller before the path from the
second controller goes away. This is just to give it some time to settle in
cases like that, so I/O can continue. The value of 30 was suggested by my
predecessor, but I think is largely arbitrary."

Cc: Sean Stewart <Sean.Stewart@netapp.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: device-mapper development <dm-devel@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
libmultipath/hwtable.c