public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Linus Torvalds <torvalds@transmeta.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: Aic7x_x_x 6.3.4 && Aic79xx 2.0.5 Updates
Date: 26 Dec 2003 12:36:33 -0600	[thread overview]
Message-ID: <1072463795.1873.127.camel@mulgrave> (raw)
In-Reply-To: <2304040000.1072326693@aslan.scsiguy.com>

On Wed, 2003-12-24 at 22:31, Justin T. Gibbs wrote:
> The crux of the problem is that *watchdog error recovery* is happening
> at entirely the wrong level in Linux. 

So this is actually an architectural complaint, not a bug in the SCSI
mid-layer as previously stated.

[...]
> Some of the problems with this strategy are:
> 
> 1) During recovery, access to perfectly viable devices is cut off.
> 
> 2) The mid-layer doesn't know which of the timed-out commands is the root
>    cause of the failure.  It assumes, since it doesn't have access to
>    better information, that all commands that have timed-out are equally
>    dead.
> 
> 3) If the mid-layer happens to abort a command that *is* the root cause
>    of the failure, the completions of all the "released" commands are
>    ignored.  This causes the mid-layer to request aborts for commands
>    that are not outstanding and then replay these commands that have
>    already completed successfully.  The replay may have unintended
>    side-effects - replay order is not maintained and no thought is given
>    to non-DASD devices where replay is destructive.  The replay may
>    also occur on a device that never really failed, but what held off
>    due to an error on another device.
> 
> 4) The TUR that occurs after each abort causes the recovery process to
>    take an inordinate amount of time.  Consider that the mid-layer can't
>    pick the most likely command to abort and that with lots of commands
>    outstanding chances are that at least half of the commands will have
>    to be aborted before the *right one* is aborted.

But your complaint is only that recovery takes longer than you think you
can do in the driver.

If error recovery were critical path in SCSI performance, this might be
a consideration, but it isn't...error recovery should be the exception,
not the rule.

[...]
> In general, I prefer the CAM model.  Briefly, this means, let the
> HBA drivers do what they can do best, provide as much information to
> the peripheral drivers so they can do their job correctly, and provide
> a "mid-layer" to simply route commands between the two.  This avoids
> having a mid-layer that second guesses, often incorrectly, both ends
> of the system.

The CAM (Common Access Model) was last updated in 1995 and is extremely
SCSI-2 (and hence parallel SCSI) specific.  The successive t10
committees charged with rewriting it have never successfully produced a
draft standard that has been published on the t10 site.

The linux SCSI subsystem follows the SAM (Scsi Architecture Model) which
was published as the backbone to SCSI-3 (SAM-3 was last updated in
November 2003).  I find it's command/transport separation extremely
appealing.  It has helped us to add new transports like Fibre and Even
SATA to the mix with relative ease.  This lack of command/transport
separation is, in my view, the biggest hole in CAM, and the reason why
we'll be continuing with SAM for Linux SCSI.

I cannot deny that the current error handler, trying to be all things to
all devices/transports, is out of kilter with this vision...it should,
at the very least have transport and device components...However, in
2.6, it does at least work.

On the Futures roadmap for the block layer in 2.7 is stackable error
recovery (you can already see the beginnings of this in the fastfail
processing) which will form the basis of async I/O, multi-path and
software RAID.

>From a technical perspective, the way you try to thwart mid-layer error
recovery: intercept all the SCSI timers and substitute your own, is
extremely ugly (and leads to quite a bit of code duplication) but it's
surely going to cause a conflict with the evolving stackable error
handling.

If you want to help us with the transport and device separations of the
error handler, you're more than welcome, but trying to pull all error
handling into your driver isn't useful because it adds layering
violations, promotes compatibility problems and cannot be used by any
other driver.

James



  reply	other threads:[~2003-12-26 18:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-03 23:51 (unknown) Justin T. Gibbs
2003-06-03 23:58 ` Marc-Christian Petersen
2003-06-04  1:34 ` Aic7x_x_x 6.2.36 && Aic79xx 1.3.10 Updates Justin T. Gibbs
2003-12-24 16:58   ` Aic7x_x_x 6.3.4 && Aic79xx 2.0.5 Updates Justin T. Gibbs
2003-12-24 17:50     ` James Bottomley
     [not found]       ` <2148850000.1072292121@aslan.scsiguy.com>
2003-12-24 19:05         ` James Bottomley
2003-12-25  4:31           ` Justin T. Gibbs
2003-12-26 18:36             ` James Bottomley [this message]
2003-12-27  0:13               ` Justin T. Gibbs
2003-12-27  3:20                 ` James Bottomley
2003-12-27  4:26                   ` Justin T. Gibbs
2003-12-27  6:08                     ` Jeff Garzik
2003-12-27 15:11                     ` Alan Cox
2003-12-27 15:47                       ` Justin T. Gibbs
2003-12-27 15:52                     ` James Bottomley
2003-12-27 15:17               ` Alan Cox
2003-12-27 15:54                 ` James Bottomley
2003-12-27 23:55                   ` Alan Cox
2003-12-27 16:02                 ` Justin T. Gibbs

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=1072463795.1873.127.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gibbs@scsiguy.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=torvalds@transmeta.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