From: Rogier Wolff <R.E.Wolff@harddisk-recovery.nl>
To: linux-kernel@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Subject: Driver retries disk errors.
Date: Mon, 30 Aug 2004 18:39:31 +0200 [thread overview]
Message-ID: <20040830163931.GA4295@bitwizard.nl> (raw)
Hi,
We encounter "bad" drives with quite a lot more regularity than other
people (look at the Email address). We're however, wondering why the
IDE code still retries a bad block 8 times? By the time the drive
reports "bad block" it has already tried it several times, including a
bunch of "recalibrates" etc etc. For comparison, the Scsi-disk driver
doesn't do any retrying.
So, why do we still do this?
- The driver may still work for MFM drives and less "intelligent"
controllers?
- Someone has recently seen that this actually helps?
In fact we regularly are able to recover data from drives: we have a
userspace application that retries over and over again, and this
sometimes recovers "marginal" blocks. This could be considered "good
practise" if there is a filesystem requesting the block. On the other
hand, when this happens, the drive is usually beyond being usable for
a filesystem: if we recover one block this way, the next block will be
errorred and the filesystem "crashes" anyway. In fact this behaviour
may masquerade the first warnings that something is going wrong....
So, I'm arguing for: We remove the retry code alltogether, OR we make
an option to re-enable the retry code for MFM era drives(*) (Note: those
are more than 10 years old, so almost (but not quite) extinct).
Roger.
(*) Note: Tested last month: The driver still works for MFM
drives. However, the initialization apparently is not enough
anymore. The drive did not work when the BIOS didn't think there was a
drive.
--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
next reply other threads:[~2004-08-30 16:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 16:39 Rogier Wolff [this message]
2004-08-30 17:46 ` Driver retries disk errors 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-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
2004-08-31 16:12 ` Alan Cox
2004-08-31 22:55 ` Christer Weinigel
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=20040830163931.GA4295@bitwizard.nl \
--to=r.e.wolff@harddisk-recovery.nl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).