From: Mike Christie <michaelc@cs.wisc.edu>
To: device-mapper development <dm-devel@redhat.com>
Cc: axboe@suse.de, linux-scsi@vger.kernel.org
Subject: Re: [dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error values
Date: Wed, 28 Sep 2005 21:28:56 -0500 [thread overview]
Message-ID: <433B5168.1020405@cs.wisc.edu> (raw)
In-Reply-To: <C2EEB4E538D3DC48BF57F391F422779321ACB6@SRMANNING.eng.emc.com>
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?
next prev parent reply other threads:[~2005-09-29 2:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-16 20:32 [RFC PATCH 4/4] convert scsi to blkerr error values goggin, edward
2005-09-16 20:26 ` Mike Christie
2005-09-16 20:53 ` Mike Christie
2005-09-29 2:28 ` Mike Christie [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-09-17 12:06 goggin, edward
2005-09-17 15:35 ` [dm-devel] " Mike Christie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433B5168.1020405@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=axboe@suse.de \
--cc=dm-devel@redhat.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.