On Fri, Feb 03, 2017 at 12:31:49AM +0100, Gianluca Cecchi wrote:
>    On Thu, Feb 2, 2017 at 10:53 PM, Benjamin Marzinski
>    <[1]bmarz...@redhat.com> wrote:
> 
>      > > I'm trying to mitigate inserting a timeout for my SAN devices but
>      I'm not
>      > > sure of its effectiveness as CentOS 7 behavior  of "multipathd -k"
>      and then
>      > > "show config" seems different from CentOS 6.x
>      > > In fact my attempt for multipath.conf is this
> 
>      There was a significant change in how multipath deals with merging
>      device configurations between RHEL6 and RHEL7.  The short answer is, as
>      long as you copy the entire existing configuration, and just change what
>      you want changed (like you did), you can ignore the change.  Also,
>      multipath doesn't care if you quote numbers.
> 
>      If you want to verify that no_path_retry is being set as intented, you
>      can run:
> 
>      # multipath -r -v3 | grep no_path_retry
> 
>    Hi Benjamin,
>    thank you very much for the explanations, especially the long one ;-)
>    I tried and confirmed that I has no_path_retry = 4 as expected
>    The regex matching is only for merge, correct?

No. Both RHEL6 and RHEL7 use regex matching to determine which
device configuration to use with your device, otherwise

product "^1814"

would never match any device, since there is no array with a literal
product string of "^1814". RHEL7 also uses the same regex matching to
determine which builtin device configuration a user-supplied device
configuration should modify. RHEL6 uses string matching for this. 

>    So in your example if in RH EL 7 I put this
>            device {
>                    vendor "IBM"
>                    product "^1814"
>                    no_path_retry 12
>            }
>    It would not match for merging, but it would match for applying to my
>    device (because it is put at the end of config read backwards).

correct.  The confusing point is that in the merging case, "^1814" in
the user-supplied configuration is being treaded as a string that needs
to regex match the regular expression "^1814" in the builtin
configuration. These don't match. For matching the device configuration
to the device, "^1814" in the user-supplied configuration is being
treated as a regular expression that needs to regex match the actual
product string of the device.

>    And it would apply only the no_path_retry setting, while all other ones
>    would not be picked from builtin configuration for device, but from
>    defaults in general.
>    So for example it would set path_checker not this way:
>    path_checker "rdac"
>    but this way:
>    path_checker "directio"
>    that is default..
>    correct?

exactly.

-Ben
 
> References
> 
>    Visible links
>    1. mailto:bmarz...@redhat.com
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to