[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]