On 01/14/2011 06:16 PM, Mike Snitzer wrote: > 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). > Ho-hum. Yes, and no. Yes, it is correct that persistent reservations are in fact per ITL nexus, and hence might yield different responses if retried on another path. And no, it is not entirely correct to return the standard EIO error here as then the no_path_retry mechanism might kick in and we're back to square one. That said we probably need to invent another error code with meaning 'Retry on other ITL nexus if present, but ignore no_path_retry'. 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
