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

[Mike Snitzer <snitzer@redhat.com>]

On Fri, Jan 14 2011 at 11:10am -0500,
Jonathan McDowell <noodles@earth.li> wrote:

> On Fri, Jan 14, 2011 at 10:58:54AM -0500, Mike Snitzer wrote:
> > From: Hannes Reinecke <hare@suse.de>
> > 
> > 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