public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Mokryn <markm@il.marvell.com>
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, andmike@us.ibm.com,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Problem in SCSI error handling 2.4/2.6
Date: Thu, 13 May 2004 11:21:42 +0300	[thread overview]
Message-ID: <40A33016.7010805@il.marvell.com> (raw)

According to the SCSI spec, a LUN may abort all outstanding commands in 
case of an error (bit QERR set in the control mode page).
This may occur on many SCSI/FC drives or storage systems, and will 
certainly the case for SATA (libata) when dealing with NCQ or TCQ drives.

The problem is that the Linux SCSI error handler (2.4 & 2.6) identically 
handles commands failed due to MEDIUM_ERROR and ABORTED_COMMAND by 
marking both types as NEEDS_RETRY.

What we have seen in such a case is that the error handler will simply 
requeue these commands, and in most cases, the exact scenario (several 
commands requeued and then aborted due to a single medium error) will be 
repeated ad nauseum until the retry limit. The result is often that all 
of the aborted commands are needlessly failed.

The correct fix is to never retry commands failed due to medium error. 
Rest assured that when a drive returns this status, exhaustive retries 
and error correction algorithms have been applied at the drive level. No 
storage system has the incentive of returning medium error if the error 
is recoverable.

If the error handler insists on retrying such commands, then at least 
set a lower retry limit on medium errors (though I believe this is 
pointless, and may just cause more aborted commands).

In any case - setting the same retry limit on medium errors and aborted 
commands is a bug.

-Mark




                 reply	other threads:[~2004-05-13  8:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=40A33016.7010805@il.marvell.com \
    --to=markm@il.marvell.com \
    --cc=andmike@us.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --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