[dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error v alues
goggin, edward
egoggin at emc.com
Thu Sep 29 02:41:24 UTC 2005
> -----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.
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
More information about the dm-devel
mailing list