On 9 Jan 2010, at 09:23, Neil Bothwick wrote:
On Sat, 9 Jan 2010 07:20:18 +0000, Valmor de Almeida wrote:
Sometimes the "current rate" reads 0 B/s for a long time... and "time
from last successful read" can be 8m.
Would any one know whether this is normal?
Doesn't ddrescue retry on blocks it cannot read? That would explain
the
variable read rate, even the period of zero activity. If your drive is
that badly damaged, dd would have been no use anyway.
I think Valmor is using GNU ddrescue, with which one makes the
multiple passes manually. The "-n" flag on the command line that
Valmor posted (`ddrescue -n /dev/sda /dev/sdc rescued.log`) relates to
the examples given in the GNU manual page [1]. I believe that GNU
ddrescue is the better version - it was inspired by garloff's original
work, and makes improvements, but it operates differently.
Having said that, it could just be that the drive _firmware) is making
multiple attempts to read the failing blocks before returning the
failure (or the data, in the case that a 2nd attempt to read the drive
was successful) to the host o/s. Isn't this how hard-drives work?
ddrescue worked fast here when I tried it here recently on a drive
with only one unreadable block, but Valmor's drive is failing much
more severely. TBH, I would expect reads from a badly-failing drive,
but this is an intuitive expectation, not a reasoned one. I think the
best thing he can do is hold his breath, wait until its finished and
see how if the results are readable, after running `fsck` on the
mounted filesystem.
Valmor: when I ran the `ddrescue -dr3` stage I had no success at all,
however the system was fine after a reboot & a `chkdsk`. Better than
it had been, in fact, on the old hard-drive. You might have more luck
getting *some* of the blocks showing as failed when you run it on your
drive, but don't be too disheartened if you don't.
Stroller.
[1] http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Examples
