All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Stark <gsstark@mit.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Stark <gsstark@mit.edu>, 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: 03 Sep 2004 10:27:19 -0400	[thread overview]
Message-ID: <87d613tol4.fsf@stark.xeocode.com> (raw)
In-Reply-To: <1094209696.7533.24.camel@localhost.localdomain>


Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> 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.

Well I still have a problem. It seems once this occurs that *every* further
access generates the error. Even directories that I had previously been able
to list fail.

So while my machine isn't crippled once this happens, I still can't proceed
with the recovery.

And they seem to take 12 minutes to fail. I guess that indicates they were
either trying to do 24 blocks of readahead, or some combination of readahead
and retries from a higher layer.

-- 
greg


  reply	other threads:[~2004-09-03 14:28 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 [this message]
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=87d613tol4.fsf@stark.xeocode.com \
    --to=gsstark@mit.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=brad@wasp.net.au \
    --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 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.