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: linux-kernel@vger.kernel.org, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: Crashed Drive, libata wedges when trying to recover data
Date: Fri, 03 Sep 2004 16:51:26 +0400	[thread overview]
Message-ID: <413868CE.7070303@wasp.net.au> (raw)
In-Reply-To: <87u0ugt0ml.fsf@stark.xeocode.com>

Greg Stark wrote:
> Brad Campbell <brad@wasp.net.au> writes:
> 
> 
>>Greg Stark wrote:
>>
>>
>>>Any clue what I need to do to achieve this? Is this a bug because this isn't a
>>>well-travelled code-path? (Dead drives not being something you can conjure up
>>>on demand)? Or is this indicative of more problems than just a crashed drive?
>>>This is on a stock 2.6.6 kernel tree, btw.
>>>
>>
>>Known issue, fixed in 2.6.9-rc1. Apply this to 2.6.6 and your good to go.
> 
> 
> Hm. I'm running 2.6.0-rc1 now. I'm not sure this really fixed the problem.
> 
> I get the same message and the same basic symptom -- any process touching the
> bad disk goes into disk-wait for a long time. But whereas before as far as I
> know they never came out, now they seem to come out of disk-wait after a good
> long time. But then maybe I just never waited long enough with 2.6.6.
> 
> I do still get the "ATA: abnormal status 0x59 on port 0xEFE7" so if that's a
> sign something's wrong then something's still wrong. I also now get additional
> messages that I don't recall seeing before. They're included below.
> 
> And as I said, every other process touching the drive, even in good areas,
> enters disk-wait. If I kill -9 the process generating the errors and wait a
> few minutes they seem to eventually exit disk-wait though.
> 
> This means I would be able to do the recovery in theory, but in practice it'll
> just take an infeasible length of time. I have gigs of data to go through and
> at the amount of time it takes to time out after each error it'll take me many
> days (years I think) to just to figure out which blocks to avoid.

Yep.. About 30 seconds per sector is the timeout whereas with 2.6.6 it would never do anything after 
the first timeout. Yes it's slow, yes it could probably be sped up but it is certainly indicative of 
a dodgy disk.

Use something like http://www.kalysto.org/utilities/dd_rhelp/index.en.html and you might have better 
results.

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.

I do have a dodgy drive here that I have kept around for testing, so I'll have a look at it when I 
get a tic.

Regards,
Brad

  parent reply	other threads:[~2004-09-03 12:52 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 [this message]
2004-09-03 14:09       ` Alan Cox
2004-09-04 21:58         ` Greg Stark
2004-09-05  4:02           ` Brad Campbell

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=413868CE.7070303@wasp.net.au \
    --to=brad@wasp.net.au \
    --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