From: Greg Stark <gsstark@mit.edu>
To: linux-kernel@vger.kernel.org
Cc: Jeff Garzik <jgarzik@pobox.com>
Subject: Crashed Drive, libata wedges when trying to recover data
Date: 02 Sep 2004 04:32:18 -0400 [thread overview]
Message-ID: <87oekpvzot.fsf@stark.xeocode.com> (raw)
I had a hard drive crash yesterday. I'm trying to recover as much data as
possible from it, and I'm having some success. The bad blocks seem to be only
in a few spots on the disk.
For the most part I've been able to pull data off the drive, occasionally I
see errors tar or cp just gets read errors and moves on to other files.
The errors look like:
Sep 2 03:22:07 stark kernel: ata1: DMA timeout, stat 0x21
Sep 2 03:22:07 stark kernel: ATA: abnormal status 0x59 on port 0xEFE7
Sep 2 03:22:07 stark kernel: scsi0: ERROR on channel 0, id 0, lun 0, CDB: 0x28 00 12 f7 f7 92 00 00 06 00
Sep 2 03:22:07 stark kernel: Current sda: sense = 70 3
Sep 2 03:22:07 stark kernel: ASC=11 ASCQ= 4
Sep 2 03:22:07 stark kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00 0x06 0x00 0x00 0x00 0x00 0x11 0x04
Sep 2 03:22:07 stark kernel: end_request: I/O error, dev sda, sector 318240658
However eventually libata seems to just stop working with that drive at all
and prints:
Sep 2 03:22:07 stark kernel: ATA: abnormal status 0x59 on port 0xEFE7
It prints that three times and then just disappears. The rest of the machine
is fine, the other drive on the same IDE controller also controlled by libata
is also just fine. But any process that tries to read anything from the dead
drive just enters disk-wait and never comes back.
This makes it hard to recover the directories that hit more than a few bad
blocks. Once this error comes up I have to reboot to do anything else.
Ideally I need the driver to behave as it has been until now. Reset the drive,
reset the bus, whatever it takes. But return an error to user-space and
arrange for future reads to have a fighting chance.
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.
--
greg
next reply other threads:[~2004-09-02 8:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 8:32 Greg Stark [this message]
2004-09-02 9:05 ` Crashed Drive, libata wedges when trying to recover data 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
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=87oekpvzot.fsf@stark.xeocode.com \
--to=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