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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
