[dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error v alues
Mike Christie
michaelc at cs.wisc.edu
Thu Sep 29 02:54:33 UTC 2005
goggin, edward wrote:
>
>
>
>>-----Original Message-----
>>From: linux-scsi-owner at vger.kernel.org
>>[mailto:linux-scsi-owner at vger.kernel.org] On Behalf Of Mike Christie
>>Sent: Wednesday, September 28, 2005 10:29 PM
>>To: device-mapper development
>>Cc: axboe at suse.de; linux-scsi at vger.kernel.org
>>Subject: Re: [dm-devel] RE: [RFC PATCH 4/4] convert scsi to
>>blkerr error values
>>
>>goggin, edward wrote:
>>
>>>Mike,
>>>
>>>I don't think it is reasonably possible to anticipate
>>>all possible parsing requirements for the asc and ascq
>>>portions of SCSI sense information across all device
>>>models. I'm in favor of having a "small" framework in
>>>SCSI where a SCSI sense interpreter module (per
>>>vendor & model possibly) could be registered
>>>dynamically, by dm-emc.c for instance.
>>>
>>>The extended error interpreter callout would be
>>>triggered indirectly by a call from
>>>__end_that_request_first to a extended error parser
>>>associated with the io request's queue whenever it
>>>sees a non-zero sense field of the io request.
>>>Perhaps the sense and sense_len fields in the
>>>request structure should be changed to not be
>>>SCSI specific.
>>>
>>>Also, in order to allow for more variation and detail
>>>in the interpretation of device specific SCSI asc and
>>>ascq values, the results of the interpretation should
>>>not be required to be block layer generic, but instead
>>>are saved in something like a void *bi_extended_error
>>>field of the bio. __end_that_request_first would push
>>>the results of the extended_error interpretation to the
>>>bi_extended_error field of each bio in the request,
>>>similar to how Jens's code currently works.
>>>
>>
>>I have been working on this but a issue I was wondering about
>>is what to
>>do when someone other than dm-multipath wants to know about
>>this special
>>error value. For example when we first discover devices if it
>>is passive
>>path, we have to go through the pain of the regular setup and any
>>retires that arise from it. If people are not going to complain about
>>this anymore then you can ignore this mail :) But the problem
>>(or issue
>>people gripe about) is that if there is a magic ASC/ASCQ value for
>>vendor XYZ that indicates we are sending requests to a
>>passive path then
>>who decodes the bi_extended_error value when dm-mutliapth is
>>not used?
>>Will we have to have a vendor specific bi_extended_error decoder for
>>dm-mpath, filesystems and buffer head code,
>
>
> Yes, that is what I was thinking anyway.
>
>
>>and what about SCSI?
>
>
> Not clear why scsi would need a decoder.
>
If during scsi device setup we could continue to send something like a
read capacity command to a passive path since scsi-ml does not have a
way to tell that we are sending the command to a passive path and that
it is better to not retry the command in this case.
More information about the dm-devel
mailing list