From: Patrick Mansfield <patmans@us.ibm.com>
To: Andreas Herrmann <aherrman@de.ibm.com>
Cc: Linux SCSI <linux-scsi@vger.kernel.org>, dm-devel@redhat.com
Subject: Re: fastfail operation and retries
Date: Thu, 21 Apr 2005 09:42:05 -0700 [thread overview]
Message-ID: <20050421164205.GA20482@us.ibm.com> (raw)
In-Reply-To: <20050419171953.GA8444@lion28.boeblingen.de.ibm.com>
On Tue, Apr 19, 2005 at 07:19:53PM +0200, Andreas Herrmann wrote:
> Hi,
>
> I have question(s) regarding the fastfail operation of the SCSI stack.
>
> Performing multipath-tests with an IBM ESS I encountered problems.
> During certain operations on an ESS (quiesce/resume and such) requests
> on all paths fail temporarily with an data underrun (resid is set in
> the FCP-response). In another situation abort sequences happen (see
> FC-FS).
>
> In both cases it is not a path failure but the device (ESS) reports
> error conditions temporarily (some seconds).
>
> Now on error on the first path the multipath layer initiates failover
> to other available path(s) where requests will immediately fail.
>
> Using linux-2.4 and LVM such problems did not occure. There were
> enough retries (5 for each path) to handle such situations.
>
> Now if the FASTFAIL flag is set the SCSI stack prevents retries for
> failed SCSI commands.
>
> Problem is that the multipath layer cannot distinguish between path
> and device failures (and won't do any retries for the failed request
> on the same path anyway).
>
> How can an lld force the SCSI stack to retry a failed scsi-command
> (without using DID_REQUEUE or DID_IMM_RETRY, which both do not change
> the retry counter).
>
> What about a DID_FORCE_RETRY ? Or is there any outlook when there
> will be a better interface between the SCSI stack and the multipath
> layer to properly handle retries.
We need a patch like Mike Christie had, this:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107961883914541&w=2
The scsi core should decode the sense data and pass up the result, then dm
need not decode sense data, and we don't need sense data passed around via
the block layer.
scsi core could be changed to handle device specific decoding via sense
tables that can be modified via sysfs, similar to devinfo code (well,
devinfo still lacks a sysfs interface).
For ESS, you probably also need the BLIST_RETRY_HWERROR that is in
current 2.6.12 rc.
-- Patrick Mansfield
next prev parent reply other threads:[~2005-04-21 16:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 17:19 fastfail operation and retries Andreas Herrmann
2005-04-21 16:42 ` Patrick Mansfield [this message]
2005-04-21 19:54 ` Lars Marowsky-Bree
2005-04-21 22:13 ` Patrick Mansfield
2005-04-21 22:52 ` Lars Marowsky-Bree
2005-04-22 0:22 ` Patrick Mansfield
-- strict thread matches above, loose matches on Subject: below --
2005-04-20 8:10 Andreas Herrmann
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=20050421164205.GA20482@us.ibm.com \
--to=patmans@us.ibm.com \
--cc=aherrman@de.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox