James Bottomley wrote:
On Thu, 2009-12-10 at 10:49 +0100, Hannes Reinecke wrote:
Hi James,
would you mind commenting on this patch?
We really need this if we ever want to be able to do proper error code
handling from multipath.
OK, not keen on the way you're setting req->errors.
Our big problem with FS requests is deferred or corrected errors
(basically we never want the FS to think we had a problem with them). I
think it's currently OK because block tends to believe the returned
error code rather than req->errors ... I'd just hate it if that changed
and suddenly lots of stuff broke.
I think you're just looking for the sense data, so could you look at
that and not set req->errors?
For the specific bug Hannes is fixing we only need the sense code, so
that would work. If you also pass info like the host_byte bits then we
can do something like fail a path right away for a DID_TRANSPORT* or
DID_NO_CONNECT failure, but then for other errors do something else.
RAID could also not fail the drive on transport errors, and do something
different too.
--
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
