On Tue, Jun 07, 2005 at 10:26:16AM -0500, Michael Christie wrote: > Quoting Patrick Mansfield <patmans@xxxxxxxxxx>: > > Why can't the retries be passed down via a new blk req->retries? > > > > Is that all that is needed for dm-multipath? I thought this would be a good time > to add some code to allow the finer grained control of retries that could also > be used by dm and md. For example do you only want to retry certain failures X > numbeer of times? I was looking/thinking about the scsi_scan retries not multipath. Setting retries might help dm-multipath, but I thought multipath was going to use fast fail. The "certain failures" is in question, it is not clear if fastfail (or setting retries to zero) give the right behaviour for use by dm-multipath, and it is not easy to analyze. Examples: MEDIUM_ERROR gets NEEDS_RETRY but is also handled in sd.c:sd_rw_intr(), it looks like we retry (if not fast fail), and then sd_rw_intr will do a partial retry of the error after that. So with fast fail, we never retry the entire IO. DID_BUSY_BUSY: should this not be retried for fast fail? It is HBA driver/hardware specific. The unconditional retries in scsi_io_completion() all look OK for multipath. -- Patrick Mansfield - : 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
