> On Mar 9, 2023, at 1:50 PM, Martin Wilck <mwilck@xxxxxxxx> wrote:
>
> Brian,
>
> On Thu, 2023-03-09 at 13:40 -0800, Brian Bunker wrote:
>>
>> Martin,
>>
>> Sorry I bounce between kernel versions a lot since most of the
>> problems which find their way to us are released Linux versions
>> whose kernels are quite a bit older than upstream.I got a chance
>> to try the proposed solutions. The PATH_GHOST above does what
>> I am looking for which is not to have the path checker fail the path.
>>
>> This also works as your earlier comments suggest. This does seem
>> clearer as to what is happening on the path:
>>
>
> I apologize for being slow, but I don't quite understand this response.
> Have you tested Ben's patch set? Does it work for you? Is the patch
> below meant to be applied on top of Ben's work?
>
> Martin
Martin,
This is just a patch I made instead of the original patch to verify
using PATH_PENDING would work in our case, and it does. It has
no relationship to anything Ben was doing.
Thanks,
Brian
>
>> diff --git a/libmultipath/checkers.c b/libmultipath/checkers.c
>> index fdb91e17..50f0773e 100644
>> --- a/libmultipath/checkers.c
>> +++ b/libmultipath/checkers.c
>> @@ -343,6 +343,7 @@ static const char
>> *generic_msg[CHECKER_GENERIC_MSGTABLE_SIZE] = {
>> [CHECKER_MSGID_UP] = " reports path is up",
>> [CHECKER_MSGID_DOWN] = " reports path is down",
>> [CHECKER_MSGID_GHOST] = " reports path is ghost",
>> + [CHECKER_MSGID_PENDING] = " reports path is transitioning",
>> [CHECKER_MSGID_UNSUPPORTED] = " doesn't support this device",
>> };
>>
>> diff --git a/libmultipath/checkers.h b/libmultipath/checkers.h
>> index ea1e8af6..4fbad621 100644
>> --- a/libmultipath/checkers.h
>> +++ b/libmultipath/checkers.h
>> @@ -111,6 +111,7 @@ enum {
>> CHECKER_MSGID_UP,
>> CHECKER_MSGID_DOWN,
>> CHECKER_MSGID_GHOST,
>> + CHECKER_MSGID_PENDING,
>> CHECKER_MSGID_UNSUPPORTED,
>> CHECKER_GENERIC_MSGTABLE_SIZE,
>> CHECKER_FIRST_MSGID = 100, /* lowest msgid for checkers
>> */
>>
>> diff --git a/libmultipath/checkers/tur.c
>> b/libmultipath/checkers/tur.c
>> index 551dc4f0..e1742c2b 100644
>> --- a/libmultipath/checkers/tur.c
>> +++ b/libmultipath/checkers/tur.c
>> @@ -179,7 +179,7 @@ retry:
>> else if (key == 0x2) {
>> /* Not Ready */
>> /* Note: Other ALUA states are either UP or
>> DOWN */
>> - if( asc == 0x04 && ascq == 0x0b){
>> + if (asc == 0x04 && ascq == 0x0b) {
>> /*
>> * LOGICAL UNIT NOT ACCESSIBLE,
>> * TARGET PORT IN STANDBY STATE
>> @@ -187,6 +187,14 @@ retry:
>> *msgid = CHECKER_MSGID_GHOST;
>> return PATH_GHOST;
>> }
>> + if (asc == 0x04 && ascq == 0x0a) {
>> + /*
>> + * LOGICAL UNIT NOT ACCESSIBLE,
>> + * TARGET PORT IN TRANSITION STATE
>> + */
>> + *msgid = CHECKER_MSGID_PENDING;
>> + return PATH_PENDING;
>> + }
>> }
>> *msgid = CHECKER_MSGID_DOWN;
>> return PATH_DOWN;
>>
>> This change also keeps the path from being failed by the checker.
>> It seems to go into and out of transitioning from other states.
>>
>> Thanks,
>> Brian
>>>
>>>>>
>>>>> The default transitioning timeout is 60s, and in my experience,
>>>>> even if
>>>>> the hardware overrides it, it's rarely more than a few minutes.
>>>>> After
>>>>> that, the kernel will set the state to STANDBY.
>>>> Yes. The case of a target keeping a path in the transitioning
>>>> state
>>>> Indefinitely is handled by the device handler.
>>>>>
>>>>> Unless we're both overlooking something, I agree with you that
>>>>> PATH_PENDING is the right thing to do for TRANSITIONING. When a
>>>>> device
>>>>> is in transition between states, we _want_ to check it often to
>>>>> make
>>>>> sure we notice when the target state is reached.
>>>>>
>>>>> We must then be careful not to overload PATH_PENDING with too
>>>>> many
>>>>> different meanings. But I don't see this as a big issue
>>>>> currently.
>>>>>
>>>>> Regards
>>>>> Martin
>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Martin
>>
>>
>
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
