On Fri, 2009-03-13 at 11:37 -0400, Konrad Rzeszutek wrote:
> Hey Mike,
>
> I was having a problem with one of the SATA controllers at work and traced it
> down to enclosure. But during that time I found out that the error handler
> of bio's issued from SCSI block vs the multipath block driver act differently.
>
> The "scsi_eh_flush_done_q" is the one that controls whether the I/Os should
> be repeated or returned back. Earlier in the days it would check the
> bio->flags to see if the REQ_FAILFAST* attributes were set, but nowadays
> it is more discriminating and depending on the host_byte(scmd->result) figures
> out if needs to check for the REQ_FAILFAST* attribute.
>
> The end result is that the bio's mapped through multipath have the same
> logic as through the SCSI block. Compared to Linux releases in RHEL53, SLES10
> the behaviour is different.
>
> So my question is that OK? From the perspective of dm-mpath it looks as
> if the device driver now does the retry/re-issue and ignores the FAILFAST
> attribute. Instead of allowing dm-mpath to be the ...umm "brain" behind this.
I can try: SCSI errors fall into three categories:
1. Driver or Host (as in kmalloc failed while the driver was
sending the packet out or the driver firmware failed and needs
resetting).
2. Transport errors (Parity/CRC error on the bus, transport failed
to connect to end device etc)
3. Device errors (device actually responded with an error, like
MEDIUM_ERROR or NOT_READY).
You can see that errors in category 3 (Device) aren't going to change if
you simply change path, so we should be doing normal error handling.
Likewise, errors in category 1 (Driver or Host) are in the same bucket;
worse, some errors in this category (like firmware failure) need SCSI
error handling to fix: if we switch path they never recover and your
availability reduces.
The idea of the changes were to separate known transport errors (which
could be fixed by switching paths) from other errors which couldn't and
should still be handled via normal eh procedures (previously we'd just
switched paths for every retryable error and never got around to
actually seeing if the SCSI error handler could fix it).
James
--
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
