From: Erik Mouw <erik@harddisk-recovery.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rogier Wolff <R.E.Wolff@harddisk-recovery.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ide@vger.kernel.org
Subject: Re: Driver retries disk errors.
Date: Tue, 31 Aug 2004 19:00:16 +0200 [thread overview]
Message-ID: <20040831170016.GF17261@harddisk-recovery.com> (raw)
In-Reply-To: <1093965233.599.8.camel@localhost.localdomain>
On Tue, Aug 31, 2004 at 04:13:54PM +0100, Alan Cox wrote:
> On Maw, 2004-08-31 at 16:56, Erik Mouw wrote:
> > The SCSI disk driver has been doing a single retry for quite some time
> > and it hasn't really bitten people. Why would the IDE disk driver be
> > different? The only case I can imagine a retry would be OK, is when we
> > get an UDMA CRC error (caused by bad cables).
>
> Retries also pop up in other less obvious cases and conveniently paper
> over a wide variety of timeouts, power management quirks and drives just
> having a random fit. Eight is probably excessive in all cases.
There are indeed all sorts of other retries in various layers, the
worst one when the kernel tries to read-ahead a couple of blocks on an
IDE disk(1). You can work around them with raw IO or O_DIRECT.
> For non hard disk cases many devices do want and need retry.
And many others do not. CompactFlash readers are usually implemented as
a USB storage device, which on its turn is implemented as a SCSI
"disk". So far I haven't seen a CompactFlash which could be "fixed" by
retries.
iSCSI appliances can also make things worse: when the target machine is
implemented as a simple "pass everything to the real SCSI disk" device,
it's not really different from a directly connected SCSI disk. However,
when the iSCSI target interprets the SCSI commands and has its own way
to deal with bad blocks (i.e.: it retries the blocks), things can get
very bad when the kernel also uses a couple of retries.
In my experience it would be good if the IDE disk driver would behave
like the SCSI disk driver: no retries on a bad block. I agree that it
would be a good idea to make it configurable through the block layer to
avoid code duplication (blockdev --getretries/--setretries).
Erik
(1) Imagine an application doing a linear read on a file with an 8
block read ahead and the last block being bad. The kernel will try to
read that bad block 16 times, but because the IDE driver also has 8
retries, the kernel will try to read that bad block *64* times. It
usually takes an IDE drive about 2 seconds to figure out a block is
bad, so the application gets stuck for 2 minutes in that single bad
block.
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
next prev parent reply other threads:[~2004-08-31 17:00 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 16:39 Driver retries disk errors Rogier Wolff
2004-08-30 17:46 ` Theodore Ts'o
2004-08-30 18:26 ` James Courtier-Dutton
2004-08-30 22:25 ` Rogier Wolff
2004-08-31 11:38 ` Alan Cox
2004-09-02 16:23 ` Eric Mudama
2004-08-31 15:16 ` Bill Davidsen
2004-08-30 22:17 ` Rogier Wolff
2004-08-31 11:45 ` Alan Cox
2004-08-31 13:45 ` Andre Hedrick
2004-08-31 13:54 ` Rogier Wolff
2004-08-31 14:12 ` Alan Cox
2004-08-31 15:56 ` Erik Mouw
2004-08-31 15:13 ` Alan Cox
2004-08-31 17:00 ` Erik Mouw [this message]
2004-08-31 16:12 ` Alan Cox
2004-09-01 15:18 ` Bill Davidsen
2004-09-01 14:46 ` Alan Cox
2004-09-01 18:54 ` Bill Davidsen
2004-09-01 15:28 ` Romano Giannetti
2004-09-01 14:44 ` Alan Cox
2004-09-01 23:14 ` Rogier Wolff
2004-09-02 9:29 ` Alan Cox
2004-09-02 10:54 ` Rogier Wolff
2004-09-02 14:30 ` John Stoffel
2004-09-02 14:59 ` Alan Cox
2004-09-02 16:07 ` John Stoffel
2004-09-02 16:26 ` Eric Mudama
2004-08-31 22:55 ` Christer Weinigel
[not found] <fa.d48te6f.1ol6tbb@ifi.uio.no>
[not found] ` <fa.eti1vu1.2nqlj5@ifi.uio.no>
2004-08-31 0:17 ` Robert Hancock
2004-09-01 23:04 ` Rogier Wolff
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=20040831170016.GF17261@harddisk-recovery.com \
--to=erik@harddisk-recovery.com \
--cc=R.E.Wolff@harddisk-recovery.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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 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.