bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Reading past errors on a non-scsi drive


From: Dave Burton
Subject: Re: [Bug-ddrescue] Reading past errors on a non-scsi drive
Date: Mon, 02 Apr 2007 10:52:12 -0400 (EDT)

James, the problem is probably not the defective disk drive,
but, rather, the IDE controller you are using it with.  The
disk drive won't wait forever.  It might be up to 10-15
seconds, but not forever.  "Promise" brand controllers are
especially bad -- they will often either freeze or just crash
the computer if they hit a bad block on the disk.  Use a
different computer and the problem will probably go away.

Alternately, you can try disabling DMA; e.g.,

hdparm -d0 /dev/hdc

That might also avoid the problem, though it'll slow down the
data recovery process, too.

-Dave



address@hidden (James Bardin) wrote:

> Hello,
>
> This may be a feature request, or just advice is it's already possible.
>
> I'm trying to read through a disk in which there are errors that cause
> the disk to wait indefinitely. (I've had to recover many disks in this
> state, so I'm surprised that I can't find a info on this)
> When this happens on a scsi disc, the read times out, the controller
> dumps the memory, and we move on.
> On other types of disks, we hang. I've tried reading both from the block
> device, and raw character devices.
>
> My current solution is to use a usb adapter, and pull the connection
> when it stops reading, then start again from a different block. This is
> fine when there a few bad areas, but I'm looking for an automated
> solution for more serious recovery.
>
> I'm not sure if this is even possible without additional features in the
> kernel. I've been following a related thread on lkml about a true forced
> unmount that would drop pending io:
> http://www.gossamer-threads.com/lists/linux/kernel/745783
>
> Or, if someone knows a way to forcefully remove, and reinitialize a usb
> device via software, I could use that as a workaround for now.
>
> Thanks
> -jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]