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, and what about SCSI?
-- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
