From: Mike Christie <michaelc@cs.wisc.edu>
To: device-mapper development <dm-devel@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>, linux-scsi@vger.kernel.org
Subject: Re: [dm-devel] Re: [PATCH] Always pass result and sense on request completion
Date: Thu, 10 Dec 2009 11:03:33 -0600 [thread overview]
Message-ID: <4B2129E5.9020205@cs.wisc.edu> (raw)
In-Reply-To: <1260463457.2457.80.camel@mulgrave.site>
James Bottomley wrote:
> On Thu, 2009-12-10 at 10:49 +0100, Hannes Reinecke wrote:
>> Hi James,
>>
>> would you mind commenting on this patch?
>> We really need this if we ever want to be able to do proper error code
>> handling from multipath.
>
> OK, not keen on the way you're setting req->errors.
>
> Our big problem with FS requests is deferred or corrected errors
> (basically we never want the FS to think we had a problem with them). I
> think it's currently OK because block tends to believe the returned
> error code rather than req->errors ... I'd just hate it if that changed
> and suddenly lots of stuff broke.
>
> I think you're just looking for the sense data, so could you look at
> that and not set req->errors?
>
For the specific bug Hannes is fixing we only need the sense code, so
that would work. If you also pass info like the host_byte bits then we
can do something like fail a path right away for a DID_TRANSPORT* or
DID_NO_CONNECT failure, but then for other errors do something else.
RAID could also not fail the drive on transport errors, and do something
different too.
next prev parent reply other threads:[~2009-12-10 17:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-19 12:24 [PATCH] Always pass result and sense on request completion Hannes Reinecke
2009-12-10 9:49 ` Hannes Reinecke
2009-12-10 16:44 ` James Bottomley
2009-12-10 17:03 ` Mike Christie [this message]
2009-12-10 17:26 ` [dm-devel] " James Bottomley
2009-12-10 17:31 ` Boaz Harrosh
2009-12-11 7:32 ` 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=4B2129E5.9020205@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox