On Fri, Jan 14 2011 at 11:10am -0500, Jonathan McDowell <noodles@xxxxxxxx> wrote: > 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). Very good point (as I think you're correct). Technically a reservation conflict is retryable across _different_ paths but (relative to the error path as it relates to multipath) it appears Hannes elected to go with the conservative approach of always failing the IO upward given the potential for data corruption when queue_if_no_path is used. Hannes previously touched on this here: https://www.redhat.com/archives/dm-devel/2009-November/msg00190.html "This also solves a potential data corruption with multipathing and persistent reservations. When queue_if_no_path is active multipath will queue any I/O failure (including those failed with RESERVATION CONFLICT) until the reservation status changes. But by then I/O might have been ongoing on the other paths, thus the delayed submission will severely corrupt your data." Even in the context of that older SCSI sense-based mpath patchset a reservation conflict would always fail upward (regardless of path count and/or queue_if_no_path). All said, the above doesn't excuse what seems to be a mis-categorization of reservation conflict as a pure non-retryable TARGET_FAILURE (EREMOTEIO). But I'd like to defer to Hannes for the authorative answer ;) Regards, Mike -- 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
