On 02/28/2014 02:58 AM, Mike Christie wrote:
> On 02/27/2014 06:14 PM, Stewart, Sean wrote:
>> This allows the sd driver to retry commands like read capacity until a
>> LUN is ready, rather than giving up after three retries.
>>
>> In NetApp E-Series, a controller can return not ready like this when it
>> quiesces I/O on the controller that just came on the network, during a
>> firmware upgrade procedure, and retrying the command at the midlayer
>> will allow the discovery to complete, successfully.
>>
>> Signed-off-by: Sean Stewart <sean.stewart@xxxxxxxxxx>
>> ---
>> drivers/scsi/device_handler/scsi_dh_alua.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
>> index 5248c88..95d87fe 100644
>> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
>> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
>> @@ -454,6 +454,11 @@ static int alua_check_sense(struct scsi_device *sdev,
>> {
>> switch (sense_hdr->sense_key) {
>> case NOT_READY:
>> + if (sense_hdr->asc == 0x04 && sense_hdr->ascq == 0x01)
>> + /*
>> + * LUN Not Ready -- In process of becoming ready
>> + */
>> + return ADD_TO_MLQUEUE;
>
> It seems like the check_sense callout is being used to work around
> scsi-ml in a lot of the additions that are not alua specific. If this is
> meant for a specific target then it should not be here. If this is
> non-alua specific behavior then it should also not be here either.
>
> If the IO was not a REQ_TYPE_BLOCK_PC request, then it would retried by
> scsi_io_completion. Same with the other ones like inquiry data changed,
> report luns data changed, etc.
>
> Are we sure we don't want to fix the REQ_TYPE_BLOCK_PC/scsi_execute*
> users to retry, or to add some new flag that those users can use that
> tells scsi-ml to retry like it normally would so callers do not have to
> check for all these errors, or just add these to scsi_decide_disposition?
>
Yes, that's definitely a better idea. I've stumbled across this
issue several times now.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
