All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian King <brking@us.ibm.com>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: linuxppc64-dev@ozlabs.org, linux-scsi@vger.kernel.org, matthew@wil.cx
Subject: Re: Symbios PCI error recovery [Was: Re: [PATCH/RFC] ppc64: EEH + SCSI recovery (IPR only)]
Date: Fri, 01 Apr 2005 09:27:22 -0600	[thread overview]
Message-ID: <424D685A.6070505@us.ibm.com> (raw)
In-Reply-To: <20050401060834.GB29734@colo.lackof.org>

Grant Grundler wrote:
>>>You want everything moved back to the "queued" state or failed
>>>(flush pending IO so upper layers can retry if they want).
>>
>>Upper layer is the linux block device; my understanding is that it does
>>not retry, nor do the filesystems above that.  Passing errors upwards
>>seems to be pretty darned fatal.  My goal is to limit retries to the
>>driver.
> 
> 
> That's a bad idea. Been there done that.
> 
> Upper layers can be alot smarter about retries than the driver ever
> could be. While the driver knows more about the transport and why
> someting might fail, upper layers will know alternate pathes 
> to the same devices or to the same data on different devices.
> Upper layers also set the recovery policy for particular storage.
> 
> Trying to do recovery transperently in the drivers is going to also
> mess up other high level SW like Service Guard or LifeKeeper.
> They want to know when a path has failed, log it, and make sure
> someone gets sent to service the HW if threshholds are exceeded.
> 
> Let higher layers like dm, VxFS, LVM worry about recovery.

The sym2 driver should fail everything back with DID_ERROR.
In most cases, the scsi midlayer will retry if the upper layer allows
retries and you will get the behavior you desire. If retries are not
allowed, like for a tape device, the command will get failed back to the
upper layer driver.

-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

      reply	other threads:[~2005-04-01 15:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050223002409.GA10909@austin.ibm.com>
     [not found] ` <20050223174356.GH13081@kroah.com>
     [not found]   ` <1109207532.5384.32.camel@gaston>
     [not found]     ` <20050224013137.GF2088@austin.ibm.com>
     [not found]       ` <20050226063609.GC7036@colo.lackof.org>
2005-03-21 23:10         ` Symbios PCI error recovery [Was: Re: [PATCH/RFC] ppc64: EEH + SCSI recovery (IPR only)] Linas Vepstas
2005-03-22 17:38           ` Brian King
2005-03-31 20:14             ` Linas Vepstas
2005-04-01  6:15               ` Grant Grundler
2005-03-22 17:57           ` Grant Grundler
2005-03-31 20:06             ` Linas Vepstas
2005-04-01  6:08               ` Grant Grundler
2005-04-01 15:27                 ` Brian King [this message]

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=424D685A.6070505@us.ibm.com \
    --to=brking@us.ibm.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=matthew@wil.cx \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.