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@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html