From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Eiichi Tsukata <eiichi.tsukata.xh@hitachi.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v2] scsi: Add 'retry_timeout' to avoid infinite command retry
Date: Thu, 06 Feb 2014 21:46:43 -0800 [thread overview]
Message-ID: <1391752003.22335.67.camel@dabdike> (raw)
In-Reply-To: <20140207002241.11465.87367.stgit@ltc223.sdl.hitachi.co.jp>
On Fri, 2014-02-07 at 09:22 +0900, Eiichi Tsukata wrote:
> Currently, scsi error handling in scsi_io_completion() tries to
> unconditionally requeue scsi command when device keeps some error state.
> For example, UNIT_ATTENTION causes infinite retry with
> action == ACTION_RETRY.
> This is because retryable errors are thought to be temporary and the scsi
> device will soon recover from those errors. Normally, such retry policy is
> appropriate because the device will soon recover from temporary error state.
> But there is no guarantee that device is able to recover from error state
> immediately. Actually, we've experienced an infinite retry on some hardware.
> Therefore hardware error can results in infinite command retry loop.
Could you please add an analysis of the actual failure; which devices
and what conditions.
> This patch adds 'retry_timeout' sysfs attribute which limits the retry time
> of each scsi command. This attribute is located in scsi sysfs directory
> for example "/sys/bus/scsi/devices/X:X:X:X/" and value is in seconds.
> Once scsi command retry time is longer than this timeout,
> the command is treated as failure. 'retry_timeout' is set to '0' by default
> which means no timeout set.
Don't do this ... you're mixing a feature (which you'd need to justify)
with an apparent bug fix.
Once you dump all the complexity, I think the patch boils down to a
simple check before the action switch in scsi_io_completion():
if (action != ACTION_FAIL &&
time_before(cmd->jiffies_at_alloc + wait_for, jiffies)) {
action = ACTION_FAIL;
description = "command timed out";
}
James
next prev parent reply other threads:[~2014-02-07 5:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1391579254-26204-1-git-send-email-eiichi.tsukata.xh@hitachi.com>
2014-02-05 5:47 ` [REVIEW PATCH] scsi: Add 'retry_timeout' to avoid infinite command retry Eiichi Tsukata
2014-02-05 16:55 ` James Bottomley
2014-02-06 4:11 ` Eiichi Tsukata
2014-02-07 0:22 ` [PATCH v2] " Eiichi Tsukata
2014-02-07 5:46 ` James Bottomley [this message]
2014-02-07 6:15 ` Libo Chen
2014-02-11 1:33 ` Eiichi Tsukata
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=1391752003.22335.67.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=eiichi.tsukata.xh@hitachi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=yrl.pp-manager.tt@hitachi.com \
/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;
as well as URLs for NNTP newsgroup(s).