public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brad Campbell <brad@wasp.net.au>
To: Greg Stark <gsstark@mit.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: Crashed Drive, libata wedges when trying to recover data
Date: Sun, 05 Sep 2004 08:02:24 +0400	[thread overview]
Message-ID: <413A8FD0.6090909@wasp.net.au> (raw)
In-Reply-To: <87y8jppugw.fsf@stark.xeocode.com>

Greg Stark wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> 
>>>Jeff, do we really have to wait 30 seconds for a timeout? If the drive hits an unreadble spot I 
>>>would have thought it would come back to us with a read error rather than timing out the command.
>>
>>The drive will retry for a few seconds then fail. The failure now
>>generates a SCSI medium error to the core scsi layer and it does like to
>>issue a few retries. The default retry count for scsi is probably too
>>high for SATA given the drive retries.
> 
> 
> Certainly over an hour seems a little excessive:
> 
> $ time dd bs=512 count=1  if=/dev/sda4 of=/dev/null
> dd: reading `/dev/sda4': Input/output error
> 0+0 records in
> 0+0 records out
> 
> real    67m59.382s
> user    0m0.001s
> sys     0m0.002s

Yes. I noted that even when reading a single block, the block layer does a large read ahead request 
and the entire request times out block by block. I have been meaning to have a look at it and see 
what is required to get it to time out like SCSI/USB devices appear to (which is fail the entire 
request on error).

I'm also not sure there is not another issue lurking in there, but when it takes an hour to recover 
from a bad block read it does slow down testing somewhat ;p)

Regards,
Brad

      reply	other threads:[~2004-09-05  4:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-02  8:32 Crashed Drive, libata wedges when trying to recover data Greg Stark
2004-09-02  9:05 ` Brad Campbell
2004-09-03  4:52   ` Greg Stark
2004-09-03  5:13     ` Greg Stark
2004-09-03 11:08     ` Alan Cox
2004-09-03 14:27       ` Greg Stark
2004-09-03 13:53         ` Alan Cox
2004-09-03 15:58           ` Greg Stark
2004-09-03 15:09             ` Alan Cox
2004-09-03 16:47               ` Greg Stark
2004-09-03 17:08                 ` Eric Mudama
2004-09-03 17:35                   ` Greg Stark
2004-09-03 17:57                   ` Greg Stark
2004-09-03 19:45                     ` Brad Campbell
2004-09-04  0:10                     ` Eric Mudama
2004-09-03 12:51     ` Brad Campbell
2004-09-03 14:09       ` Alan Cox
2004-09-04 21:58         ` Greg Stark
2004-09-05  4:02           ` Brad Campbell [this message]

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=413A8FD0.6090909@wasp.net.au \
    --to=brad@wasp.net.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gsstark@mit.edu \
    --cc=jgarzik@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox