linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Rogier Wolff <R.E.Wolff@harddisk-recovery.nl>
Cc: 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 15:12:52 +0100	[thread overview]
Message-ID: <1093961570.597.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20040831135403.GB2854@bitwizard.nl>

On Maw, 2004-08-31 at 14:54, Rogier Wolff wrote:
> So, can we agree on: 
> 	- might be needed for 
> 		- Floppies?
> 		- MO drives
> 		- older drives

Other random stuff it saves our backside on we don't know about.

> How about we set the num-retries to 1, and increase to 8 for
> "weird devices" (floppy, MO), and older drives. 

Disagree. I want it robust. If you want to set low retry counts then
the user should do so for special cases like forensics.

> I do want to make the num_retries thing a configurable parameter,
> should the autodetect get it wrong: We get drives that we want to
> recover without the kernel-level retries...

Making it configurable is good, but I can't help feeling that this
belongs at the block layer - I wonder what Jens thinks, it might well
have to be done by the driver because only the driver knows enough but
the ioctl/config option ought to be common.

> (still: I argue that you need to consider a "retry-works" error as an
> early warning that your media is going bad, and you need to get your
> data off ASAP! If the kernel silently retries and succeeds, the user
> won't notice a thing and continue using the drive (or MO media) until
> the error becomes irrecoverable. I recommend we put the retry at the
> user level. As in "person behind keyboard".)

M/O media retries generally do the right thing and have the right
effect. If you want to know if your drive is failing use SMART and ask
the drive

Remember: Storage appliance not disk. Treat it like a storage
appliance and you'll get better results.

Alan

  reply	other threads:[~2004-08-31 14:12 UTC|newest]

Thread overview: 16+ 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-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 [this message]
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=1093961570.597.2.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=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).