9

I'm recovering the HDD from my laptop that died (wouldn't boot up at all, Disk Utility reported that there were no problems, but wouldn't mount the disk). I've hooked up the HDD through the USB adapter. Running ddrescue like so:

sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log

There are no errors so far, but the average read speed has gradually dropped to 50KB/s. It was around 2MB/s at the beginning. The size of the partition is 300GB. So far I've been able to recover 160GB. I'm recovering to an HFS+ partition on my MacBook.

What could be the reasons for this slow transfer rate and how to increase it?

Braiam
  • 35,991
Mik
  • 93

2 Answers2

9

This would seem to just been how ddrescue & USB transfers work under OSX. From this thread titled: Subject: [Bug-ddrescue] ddrescue 10x slow under osx.

when working on fully functional hard drives, under linux it performs full i/o speed. when compiled under osx with the default compile flags, it is magnitude times slower, sometimes crawling to Kb/s. the problem persists if the output file is /dev/null.

That same thread also had this response.

In my experience and testing on OS X, accessing the raw character devices /dev/rdisk… is always preferable. Also the transfer speed can be further enhanced by setting a bigger Copy Block Size. A size of 512KiB (ddrescue -c 1Ki) gave me the best results in most cases.

And: OS X raw character devices DO have a defined size, so they can be easily used even in the first run. (At least in this point the notes about raw devices in the existing documentation for ddrescue do not apply to OS X.)

I don't think this is a bug in ddrescue, because other utilities like dd or cat exhibit the same behavior on OS X.

Accessing a /dev/disk… block device gives a rather slow speed, independent of the Copy Block Size used. The reading speed of a /dev/rdisk… raw character device on the other hand depends a lot on the Copy Block Size chosen:

  • 512 Byte (ddrescue -c 1, default in dd) is the slowest.
  • Setting it to 4096 Byte (ddrescue -c 8, dd bs=4K) gives the same slow speed as accessing /dev/disk…
  • ddrecue's default of 128 sectors (= 64KiB, ddrescue -c 128, dd bs=64K) brings fairly good results.
  • Multiplying that further (up to ddrescue -c 1Ki / dd bs=512K) brings maximum speed (mostly 8-12 times faster than /dev/disk…)
  • Rising above that did not increase transfer speed any further in my testing; sometimes it even decreased.

Those are the results of my own measurements, your results may vary depending on the media and IO hardware used. Maybe if some other users would share their experience, we could gain a better picture of the topic.

References

Community
  • 1
slm
  • 369,824
1

I do not know much about the HFS+ file system on MacOS, however, I just made the experience that rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat formatted USB hard drive, was starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.

Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4 file system, moved the files back on it and resumed the ddrescue process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!

Seems like exFat does not play very well with very large files (several hundred gigabytes). As already said, I do not know whether this is also the case for HFS+ but maybe you want to give ext4 a shot.

Dirk
  • 111