All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Driver retries disk errors.
Date: Wed, 01 Sep 2004 11:18:30 -0400	[thread overview]
Message-ID: <ch4oq3$fse$1@gatekeeper.tmr.com> (raw)
In-Reply-To: <1093968767.597.14.camel@localhost.localdomain>

Alan Cox wrote:
> On Maw, 2004-08-31 at 18:00, Erik Mouw wrote:
> 
>>>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.
> 
> 
> It does no harm trying. It does real harm not being conservative and
> losing peoples data. You recover people's data after its lost, the
> IDE layer's job is to make sure it doesn't get lost in the first place.
> 
> 
>>(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.
> 
> 
> Right now I know of no way to tell which is readahead for a failed
> command or of telling the block layer to forget them. Fix this at the
> block layer and IDE can abort the readahead sequence happily enough
> because IDE is too dumb to have issued further commands to the drive at
> this point.

If would probably be good to retry "read what you were asked, nothing 
more" on error, to avoid passing back errors caused by readahead. I 
suspect this would avoid some issues reading data off CD as well, where 
one software can read clean and another ends with a short image and error.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2004-09-01 15:31 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
2004-08-31 16:12             ` Alan Cox
2004-09-01 15:18               ` Bill Davidsen [this message]
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='ch4oq3$fse$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --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.