bug-ddrescue
[Top][All Lists]
Advanced

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

[Bug-ddrescue] Dealing with a disk that stops responding


From: Olaf Buddenhagen
Subject: [Bug-ddrescue] Dealing with a disk that stops responding
Date: Mon, 1 Feb 2016 11:45:17 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

Hi,

I'm running into a bunch of problems on Linux 4.4 trying to recover a
partition from a broken PATA harddisk, which fails only on a limited set
of sectors, but stops responding after trying to read any of them.
Unfortunately ddrescue 1.20 doesn't seem to support this situation very
well :-(

The recently added -J flags *looks* like it should help in this
situation -- but it turns out it doesn't really work for me :-( First of
all, it never actually fails the verify. I suppose that's caused by the
kernel's block caching -- however, neither --direct-input nor using a
raw device work on my system: in either case, all reads fail immediately
without ever even going to the actual disk. No idea what's wrong with it
:-(

But even if the verify worked in principle, it seems of limited use in
its current form. For one, AIUI it only works when there was already a
successfull read in the same run of ddrescue; while a failure on the
first attempted block will still cause ddrescue to mark the rest of the
disk as failed?

Also, it seems to me that verify failure is handled like a write error
on the output file -- which means it will never put information about
the failing cluster in the log file?

For now, I'm working with -X, which is somewhat helpful. It's a rather
manual process though, as it puts the actual failed cluster in the log
file, but nothing after that -- so the next attempt (after a power
cycle) would always continue with the next cluster: there is no way to
automatically skip a bigger chunk.

(I'm working around this by setting a large cluster size, which
sometimes does and sometimes doesn't skip enough, depending on whether
the failure was far from the end of the cluster or not...)

Also, -X only works for the first pass (copy) -- it looks like
proceeding with trimming/scraping after that will be an even more manual
process...

Any suggestions how to address these problems?

-antrik-



reply via email to

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