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