From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Greg Stark <gsstark@mit.edu>
Cc: Brad Campbell <brad@wasp.net.au>,
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: Fri, 03 Sep 2004 12:08:20 +0100 [thread overview]
Message-ID: <1094209696.7533.24.camel@localhost.localdomain> (raw)
In-Reply-To: <87u0ugt0ml.fsf@stark.xeocode.com>
On Gwe, 2004-09-03 at 05:52, Greg Stark wrote:
> 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.
This looks hopeful. You are now seeing the IDE layer error dump. Right
now it doesn't decode the LBA block number although that data is
available in the taskfile so I can knock up a test patch for you to try
if you want.
> 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.
Open the disk device directly with O_DIRECT, read in something like 64K
chunks. That won't do readahead so it gets easier to work out the
problem areas. You can now sit in a loop doing
if(pread() failed)
write blank
log
else
write data
then go back and binary search the holes it logs the next morning.
Alan
next prev parent reply other threads:[~2004-09-03 12:16 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 [this message]
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
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=1094209696.7533.24.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=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