RE: [dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error v alues

RE: [dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error v alues

[goggin, edward]

 

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org 
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Mike Christie
> Sent: Wednesday, September 28, 2005 10:29 PM
> To: device-mapper development
> Cc: axboe@suse.de; linux-scsi@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.

> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: RE: [RFC PATCH 4/4] convert scsi to blkerr error v alues

[Mike Christie]

goggin, edward wrote:
>  
> 
> 
>>-----Original Message-----
>>From: linux-scsi-owner@vger.kernel.org 
>>[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Mike Christie
>>Sent: Wednesday, September 28, 2005 10:29 PM
>>To: device-mapper development
>>Cc: axboe@suse.de; linux-scsi@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.