All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: device-mapper development <dm-devel@redhat.com>,
	James Bottomley <James.Bottomley@suse.de>,
	linux-scsi@vger.kernel.org
Subject: Re: [dm-devel] [PATCH] multipath: Evaluate request result and sense code
Date: Fri, 20 Nov 2009 08:48:49 +0100	[thread overview]
Message-ID: <4B0649E1.10106@suse.de> (raw)
In-Reply-To: <4B05A36C.2030409@cs.wisc.edu>

Mike Christie wrote:
> Hannes Reinecke wrote:
>> As we now see the result for every command we
>> can use it to make some more elaborate choices
>> if we should retry the request on another path.
>>
>> This solves a potential data corruption when
>> a request is being terminated with RESERVATION
>> CONFLICT and queue_if_no_path is active; the
>> request will be queued until the reservation
>> status changes and then transmitted.
> 
> 
> I had the same bz. To handle it I just converted the error to some other
> -EXYZ value. But like I said in my patch that I sent to the list I did
> not like it much.
> 
Yeah, that was my thought, too.
The scsi result codes simply don't fit on the -EXXX values.

> I thought of going the route you did in this patch, but thought it was
> too scsi specific. Does dasd want advanced error handling? If not, then
> I am fine since for hw handlers we assume they are always scsi_dh modules.
Well, DASD has it's own sort of problems; basically DASD will _always_
try to do it's own internal recovery by waiting for the storage array
to respond. So with DASD we basically only ever have three states:
- GOOD
- Failure as being evaluated by the _storage array_
- Don't know (if failfast is set)
And any advanced checking won't give us much here, as either the link
is on-line and we have details about the error or the link is severed
and we don't know anything.

But there's a good point, we should be doing some sort of
cross-check to determine if it really is a SCSI error.
Just to prevent any accidental spill-overs in the future.

I'll be sending a patch.

Cheers,

Hannes
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-11-20  7:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 12:25 [PATCH] multipath: Evaluate request result and sense code Hannes Reinecke
2009-11-19 19:58 ` Mike Christie
2009-11-20  7:48   ` Hannes Reinecke [this message]
2009-11-22 20:47     ` Mike Christie
2009-11-22 21:00 ` Mike Christie
2009-11-26  7:54   ` [dm-devel] " Hannes Reinecke
2009-11-26  0:25 ` Moger, Babu
2009-11-26  8:03   ` Hannes Reinecke

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=4B0649E1.10106@suse.de \
    --to=hare@suse.de \
    --cc=James.Bottomley@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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.