[Top][All Lists]

[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)


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

Any suggestions how to address these problems?


reply via email to

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