Re: [PATCH] delay transition requeues for 2 seconds - alua

[Rob Evers <revers@redhat.com>]

On 01/13/2012 12:51 PM, Rob Evers wrote:
> On 01/12/2012 05:13 PM, Hannes Reinecke wrote:
>> On 01/12/2012 08:59 PM, Mike Christie wrote:
>>> On 01/12/2012 01:54 PM, Mike Christie wrote:
>>>> alua_check_sense will return ADD_TO_MLQUEUE_DELAY then 
>>>> scsi_check_sense
>>>> will pass that up and scsi_decide_disposition will return that right
>>>> away.
>>>
>>> I mean it is one of those weird ones where we do not do the goto
>>> maybe_retry in scsi_decide_disposition, so we do not see the fast fail
>>> bit set. This happens for ADD_TO_MLQUEUE_DELAY and ADD_TO_MLQUEUE.
>>>
>> Hmm. Not sure here.
>> With the above reasoning SG_IO would be retried, too.
>> Which it most definitely isn't.
>>
>> I'll be digging deeper here tomorrow.
>>
>> Cheers,
>>
>> Hannes
>
> Hannes,
>
> I ran some tests today to verify what you said about rtpg not ending
> up executing the ADD_TO_MLQUEUE_DELAY path via scsi_softirq_done.
>
> So yes, looks like another delay is required in alua_rtpg.

It turns out that the rtpg activity on an array is limited during these
transitions and scales with the number of paths connected to the array.

What I have seen for rtpg sense codes after the first alua_rtpg retry is:

06/29/00
06/2a/06

and 1-2 retries in alua_rtpg for the first retry condition.  This is for
every path to an array.

This activity follows shortly after an array controller reboot.
The rtpg retries all occur within a second of each other.

The rtpg sense codes never match the modifications to alua_check_sense
where a ADD_TO_MLQUEUE_DELAY condition gets triggered (2/4/a).  This is
confirmed by our array vendor partner.

The 1st rtpg retries in alua_rtpg don't get delayed by the sdevice queue 
being
delayed, at least they are never seperated by 2 seconds as would 
indicate that.

I could use an explanation of why the rtpgs retries don't get delayed, 
if someone knows and would be so kind.

The alua_check_sense 2/4/a triggers the ADD_TO_MLQUEUE_DELAY condition
and this does cause the sdevice queue to delay, and this repeats every 2 
seconds
as expected during the transitions.

Hannes,

Can you revisit this?

Thanks, Rob