From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Doug Ledford <dledford@redhat.com>
Cc: Matthew Jacob <mjacob@feral.com>,
"[G_rard Roudier]" <groudier@free.fr>,
Jeremy Higdon <jeremy@classic.engr.sgi.com>,
Martin Peschke3 <MPESCHKE@de.ibm.com>,
Pete Zaitcev <zaitcev@redhat.com>,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH + RFC] Beginning of some updates to scsi mid layer
Date: Tue, 2 Jul 2002 13:27:17 +0200 (MEST) [thread overview]
Message-ID: <200207021127.NAA10291@cave.bitwizard.nl> (raw)
In-Reply-To: <20020701151553.G776@redhat.com> from Doug Ledford at "Jul 1, 2002 03:15:53 pm"
Doug Ledford wrote:
> On Mon, Jul 01, 2002 at 12:08:03PM -0700, Matthew Jacob wrote:
> > Yes, exponential backoff is good in a lot of cases. BTW- this is something I
> > want to put into cam_periph_error for FreeBSD- I want to make the retry after
> > selection timeout also have exponential delays up to retry count.
>
> Hmmm...what's the purpose on this BTW? Selection timeouts on what, fiber
> or SPI or something else?
As I'm in the data-recovery business, I've seen more than my share of
"bad disks".
I've seen (mostly IDE) cases where the retry "interrupted" the drive
while it was still recovering from the last problem, leading to a new
erorr condition, which triggered the same "lengthy recovery" in the
drive. Repeat ad inifinitum.
Exponential backoff would've helped.
If "now" we think that a retry after 1 second is right, then I would
suggest something like a "backoff factor" of 1.5, and an initial value
of 0.7 seconds.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
next prev parent reply other threads:[~2002-07-02 11:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-28 6:08 [PATCH + RFC] Beginning of some updates to scsi mid layer Martin Peschke3
2002-06-28 7:39 ` Doug Ledford
2002-06-29 1:19 ` Jeremy Higdon
2002-06-29 2:04 ` Matthew Jacob
2002-06-29 10:05 ` Doug Ledford
2002-06-29 10:37 ` Matthew Jacob
2002-07-01 21:02 ` Gérard Roudier
2002-07-01 19:08 ` Matthew Jacob
2002-07-01 19:15 ` Doug Ledford
2002-07-01 19:23 ` Matthew Jacob
2002-07-01 19:59 ` Doug Ledford
2002-07-01 20:17 ` Matthew Jacob
2002-07-02 11:27 ` Rogier Wolff [this message]
2002-06-29 10:10 ` Doug Ledford
-- strict thread matches above, loose matches on Subject: below --
2002-06-28 8:25 Martin Peschke3
2002-06-28 11:22 ` Doug Ledford
[not found] <20020619014048.B8623@redhat.com>
2002-06-19 17:44 ` Pete Zaitcev
2002-06-19 17:55 ` Matthew Jacob
2002-06-19 18:25 ` Doug Ledford
2002-06-28 5:41 ` Jeremy Higdon
2002-06-28 7:37 ` Doug Ledford
2002-06-19 0:47 Doug Ledford
2002-06-19 21:15 ` Patrick Mansfield
2002-06-20 19:45 ` Doug Ledford
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=200207021127.NAA10291@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=MPESCHKE@de.ibm.com \
--cc=dledford@redhat.com \
--cc=groudier@free.fr \
--cc=jeremy@classic.engr.sgi.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mjacob@feral.com \
--cc=zaitcev@redhat.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