Re: [PATCH v4 1/3] scsi: Detailed I/O errors

[Hannes Reinecke <hare@suse.de>]

On 01/18/2011 12:33 PM, Douglas Gilbert wrote:
> On 11-01-18 10:13 AM, Hannes Reinecke wrote:
>> Instead of just passing 'EIO' for any I/O error we should be
>> notifying the upper layers with more details about the cause
>> of this error.
>>
>> Update the possible I/O errors to:
>>
>> - ENOLINK: Link failure between host and target
>> - EIO: Retryable I/O error
>> - EREMOTEIO: Non-retryable I/O error
>> - EBADE: I/O error restricted to the I_T_L nexus
>>
>> 'Retryable' in this context means that an I/O error _might_ be
>> restricted to the I_T_L nexus (vulgo: path), so retrying on another
>> nexus / path might succeed.
>>
>> 'Non-retryable' in general refers to a target failure, so this
>> error will always be generated regardless of the I_T_L nexus
>> it was send on.
>>
>> I/O errors restricted to the I_T_L nexus might be retried
>> on another nexus / path, but they should _not_ be queued
>> if no paths are available.
> 
> Hannes,
> I don't know if it is applicable to this patch but with
> SAS when the uplink from an expander is being stressed
> (i.e. it temporarily doesn't have enough bandwidth) then
> a sense key of ABORTED COMMAND may be generated. In my
> experience retrying such a command succeeds.
> 
I guess this should be handled by scsi EH, as there
should be some sensible ASC/ASCQ values to go with
it.

This patchset is primarily for fixing up multipathing,
which has the habit of retrying failed I/Os on the
next path. For some errors this is just pointless
(eg MEDIUM ERROR), for some errors this is the desired
behaviour (namely transport errors), and for others
this is positively damaging (persistent reservation
failures).
Just plain EIO simply don't cover the whole range :-)

> 
> BTW might "vulgo" be "ergo" [Latin: therefore]?
> 
Nope. Correct etymology is from 'sermo vulgaris',
ie the language of the common people.
But maybe I should remove it for the next
round to avoid confusion.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html