[Top][All Lists]

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

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

From: Felix Ehlermann
Subject: Re: [Bug-ddrescue] Slowing down of ddrescue over time
Date: Mon, 10 Oct 2011 16:31:18 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

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:

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

reply via email to

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