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.
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.
-- 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
