All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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.