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