Hannes Reinecke wrote:
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.
What about replaceing -EXXX errors with some new BLKERR values?
Send some comments on the patch in the other mail.
--
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
