From: Mike Christie <michaelc@cs.wisc.edu>
To: "goggin, edward" <egoggin@emc.com>
Cc: dm-devel@redhat.com, axboe@suse.de, linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] convert scsi to blkerr error values
Date: Fri, 16 Sep 2005 15:53:30 -0500 [thread overview]
Message-ID: <432B30CA.7000907@cs.wisc.edu> (raw)
In-Reply-To: <432B2A71.6020305@cs.wisc.edu>
Mike Christie wrote:
> 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.
>
>
> Yeah I agree, I mentioned this before in some other mails. I think a
> module versus some table that userspace could write to were discussed.
>
> The BLKERR values were meant to be able to tell upper layer code whether
> a transport or device or driver error occured and whether the lower
> level thought it was retryable. But then I thought I could also wedge in
> the handling of the vendor specifcs by adding a vendor specific SCSI
> module that would map the their specific value to a BLKERR_* one. And as
> I said offlist it is not working perfectly becuase we are losing some
> information in the translations.
>
Oh yeah so the problem I am having is emc boxes may return "LUN Not
Ready - Manual Intervention Required". When dm-emc.c sees this error it
wants to bypass a group of paths and retry the IO but under ceratin
conditions not fail those paths. So I am not sure what to return for
this error. I thought if I redo my BLKERR so they describe the error like
BLKERR_DEV_NOT_READY
BLKERR_MANUAL_INTERVENTION_REQ
BLKERR_NOT_CONN
... and set them up as a bitmap like suggested by JamesB. I could return
BLKERR_MANUAL_INTERVENTION_REQ from a scsi module then have dm-emc.c
evaluate that value to a dm-mpaths return value of "MP_BYPASS_PG |
MP_RETRY_IO" which means bypass the priority group (group of paths) and
retry the IO.
But as more vendors use dm and they cannot use existing BLKERR values I
have to add more and more. And then we have to handle the case where
some block layer code may return BLKERR_MANUAL_INTERVENTION_REQ for
something not related to the reasons EMC's HW was returning "LUN Not
Ready - Manual Intervention Required" and we end up with getting things
wrong.
next prev parent reply other threads:[~2005-09-16 20:53 UTC|newest]
Thread overview: 8+ 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 [this message]
2005-09-29 2:28 ` [dm-devel] " Mike Christie
-- strict thread matches above, loose matches on Subject: below --
2005-09-17 12:10 goggin, edward
2005-09-17 15:41 ` Mike Christie
2005-09-17 12:06 goggin, edward
2005-08-24 9:04 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=432B30CA.7000907@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=axboe@suse.de \
--cc=dm-devel@redhat.com \
--cc=egoggin@emc.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.