Re: [Bug-ddrescue] Slowness during recovery

[Antonio Diaz Diaz]

James W. Watts wrote:
> I can't help but feel that this could have been prevented if there were 
> some way to make ddrescue jump past large chunks of bad spots. I thought 
> that was how ddrescue was supposed to work. Instead, I just experienced 
> ddrescue bogging down at the first bad sector(s) it encountered. And 
> there it remained until the drive gave up and died completely.
>
> Really, what could I have done differently? Please educate me.

This is your logfile:
> 0x00000000  0x617DC000  +
> 0x617DC000  0x00004400  *
> 0x617E0400  0x00000200  -
> 0x617E0600  0x00010000  *
> 0x617F0600  0x00000200  -
> 0x617F0800  0x00020000  *
> 0x61810800  0x0727F800  +
> 0x68A90000  0x00000C00  *
> 0x68A90C00  0x00000200  -
> 0x68A90E00  0x00010000  *
> 0x68AA0E00  0x00110000  +
> 0x68BB0E00  0x2E2B285200  ?

The lines marked with '*' are the chunks skipped by ddrescue after every 
bad sector found. As you can see ddrescue skipped a total of 256KiB 
after the 3 bad sectors found, and it found good data efficiently.

You could have tried -d (direct disc access), a raw device, or a small 
value for -c, To check if readahead or kernel caching were slowing it.

If you know the data you want is not at the beginning of the drive, you 
could have instructed ddrescue to begin reading at the correct place.

You could have restarted ddrescue after the first error, because the 
drive or the kernel can slow down persistently after the first error.

You can still try the freezer.

But even if you did all this and ddrescue found good data efficiently, 
there is always the possibility that the drive dies before all the data 
can be read from it. Sorry.


Best regards,
Antonio.