Mike Christie wrote: > Hannes Reinecke wrote: >> As we now see the result for every command we >> can use it to make some more elaborate choices >> if we should retry the request on another path. >> >> This solves a potential data corruption when >> a request is being terminated with RESERVATION >> CONFLICT and queue_if_no_path is active; the >> request will be queued until the reservation >> status changes and then transmitted. > > > I had the same bz. To handle it I just converted the error to some other > -EXYZ value. But like I said in my patch that I sent to the list I did > not like it much. > Yeah, that was my thought, too. The scsi result codes simply don't fit on the -EXXX values. > I thought of going the route you did in this patch, but thought it was > too scsi specific. Does dasd want advanced error handling? If not, then > I am fine since for hw handlers we assume they are always scsi_dh modules. Well, DASD has it's own sort of problems; basically DASD will _always_ try to do it's own internal recovery by waiting for the storage array to respond. So with DASD we basically only ever have three states: - GOOD - Failure as being evaluated by the _storage array_ - Don't know (if failfast is set) And any advanced checking won't give us much here, as either the link is on-line and we have details about the error or the link is severed and we don't know anything. But there's a good point, we should be doing some sort of cross-check to determine if it really is a SCSI error. Just to prevent any accidental spill-overs in the future. I'll be sending a patch. Cheers, Hannes > -- > 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 -- 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
