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

[Douglas Gilbert <dgilbert@interlog.com>]

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.


BTW might "vulgo" be "ergo" [Latin: therefore]?

Doug Gilbert