I agree with thinking,   it's better to check if device has a specific checker 
in its stanza firstly.

-----Original Message-----
From: Martin Wilck <martin.wi...@suse.com>
Sent: Wednesday, June 8, 2022 3:56 PM
To: bmarz...@redhat.com; christophe.varo...@opensvc.com
Cc: dm-devel@redhat.com; Chen, Yanfei
Subject: Re: [PATCH] libmultipath: unset detect_checker for clariion / Unity 
arrays


[EXTERNAL EMAIL]

On Tue, 2022-06-07 at 17:45 -0500, Benjamin Marzinski wrote:
> Dell EMC would like to always use the emc_clariion checker. Currently
> detect_checker will switch the checker to TUR for Unity arrays.
> This can cause problems on some setups with replicated Unity LUNs,
> which are handled correctly the the emc_checker, but not the TUR
> checker.
>
> Cc: vincent.ch...@dell.com
> Signed-off-by: Benjamin Marzinski <bmarz...@redhat.com>

This points us to a flaw in our logic.

It was wrong in the first place to have autodetection take precedence, even 
over "overrides". The effect for users is that whenever "path_checker" is set, 
"detect_checker no" must also be set, which is highly surprising and adds no 
benefit.

We should assume that if a device has an explicit checker configured either in 
the device configuration, overrides, or the hwtable, this checker must be used, 
and fall back to autodetection only if this is not the case.

So while this patch is alright, I'd prefer a patch that fixes the logic.

(The same could be said for detect_prio, but I don't want to make outrageous 
demands).

Martin





> ---
>  libmultipath/hwtable.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c index
> 39daadc2..415bf683 100644
> --- a/libmultipath/hwtable.c
> +++ b/libmultipath/hwtable.c
> @@ -350,6 +350,7 @@ static struct hwentry default_hw[] = {
>                 .no_path_retry = (300 / DEFAULT_CHECKINT),
>                 .checker_name  = EMC_CLARIION,
>                 .prio_name     = PRIO_EMC,
> +               .detect_checker = DETECT_CHECKER_OFF,
>         },
>         {
>                 /* Invista / VPLEX */


Internal Use - Confidential

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

Reply via email to