On 12/10/2009 06:44 PM, 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. > >From what I understood, req->errors is for private block-driver use and has no meaning to the block layer. It expects a translation of req->errors to a Linux error code passed to the blk_end_request which will be set to the bio and passed to the async_done function. Only the block-driver understand the format of req->errors. Perhaps we must make sure there is an agreement between (returned-error == 0) == (req->errors == 0) I know scsi-ml makes sure of that, so should the device manager. > I think you're just looking for the sense data, so could you look at > that and not set req->errors? > I agree that the req->errors bits where not understood outside of scsi up till now. Is multipath only compatible over scsi block devices? > James > Boaz -- 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
