Re: [Bug-ddrescue] Slowing down of ddrescue over time

[Felix Ehlermann]

Dear Richard,

On 08.10.2011 23:12, Richard Bertrand wrote:
> There is one peculiarity I have noticed, however: ddrescue is starting 
> fast and subsequently slowing down during the copy process.
A certain slowdown is normal over the entire disk as the reading speed 
of the disk depends on the location of the data.
I have found the first sectors to be ~50% faster than the last sectors 
on the same disk.
(On CAV CD or DVD drives the same effect can be observed in a more 
obvious way, the only difference is that you read from slow to fast 
while a HD reads from fast to slow.)

The massive drop in performance you are observing must therefore be 
caused by something else.
Can you exclude write caching on your destination drive as cause for the 
initially high transfer rate?

If I "ddrescue /dev/zero testfile" I get a rate of ~300MByte/s first, 
which drops dramatically as the write cache is filled and Linux has to 
flush data on the physical disk.
This is caused by the write cache on my hd.

Example run with ddrescue v1.11 (aborted after a few seconds) - note the 
average over the 750MByte:

address@hidden:/media# ddrescue /dev/zero testfile
rescued:   764150 kB,  errsize:       0 B,  current rate:    7962 kB/s
   ipos:   764150 kB,   errors:       0,    average rate:   69468 kB/s
   opos:   764150 kB,     time from last successful read:       0 s
Copying non-tried blocks...

Also I would suggest that you try writing on a filesystem other than 
NTFS - or to the device directly.
As far as I know the performance of some (older?) NTFS-implementations 
drops significantly with large files. The increased CPU usage you 
observed indicates that this could be happening in your case.

See also:
http://apcmag.com/linux_to_get_reliable_ntfs_write_support.htm
http://en.wikipedia.org/wiki/NTFS-3G#Performance

You could maybe just mount a SMB-Share from a Windows Box using CIFS (so 
you get large file support) and see if that works well for you?
(Note that SMB v1 will not get >30 MByte/s even on GBit links)

> Even so, most source disks are also ntfs-formatted as these 
> to-be-revived computers run Windows....
As ddrescue will copy on block level the source filesystem is not really 
relevant....

> Is there something I can do to keep it rescuing data at maximum speed? 
> What is getting in the way of ddrescue that it is slowing down so much?
I would suggest that you write the data directly to the destination 
device (like "ddrescue /dev/sdb /dev/sdc log") - I did not have any 
performance issues with this yet.
(Obviously the destination drive will be overwritten in this setup... 
but you'll have a windows-readable drive if your source was formatted 
NTFS or the like)


Kind Regards
Felix Ehlermann