On Fri, Jan 14, 2011 at 10:58:54AM -0500, Mike Snitzer wrote: > From: Hannes Reinecke <hare@xxxxxxx> > > 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 > > '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. ... > @@ -1486,6 +1495,7 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd) > case RESERVATION_CONFLICT: > sdev_printk(KERN_INFO, scmd->device, > "reservation conflict\n"); > + scmd->result |= (DID_TARGET_FAILURE << 16); > return SUCCESS; /* causes immediate i/o error */ > default: > return FAILED; ... > +#define DID_TARGET_FAILURE 0x10 /* Permanent target failure, do not retry on > + * other paths */ I'd have viewed a reservation conflict as being tied to a particular path, rather than the entire target. I've seen multipath setups where there are reservation issues on some of the paths but others are fine and this is expected (eg use of reservations to fence off particular paths). J. -- /-\ | It's more than good enough so I |@/ Debian GNU/Linux Developer | ain't switch'n. \- | -- 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
