I am backing up 225 GB to a Western Digital USB 2.0 hard drive but this seems really slow. Any ideas on what I could do to make this transfer faster? It's saying it will take seven hours and it is a USB 2.0-only drive.

  • Could you add more details on your situation? What options do you have? Do you have USB 3, or Firewire available to use? – bassplayer7 Mar 14 '13 at 19:27
  • USB 2.0 maxes out at about 30MB/second == 2GB / minute == 112 minutes = ~2 hours. Your only alternative is to pull the drive out of the external case and put it into a case with a faster interface, such as USB 3.0, Firewire 800, or eSATA. Or, buy a Drive Dock and pop the bare drive into that. – gosmond Mar 14 '13 at 19:28
  • sorry, thought I put that info in there. saying 5-7 hrs. It's clearly running at USB 2.0 as 1.0 would be much longer than even 7 hrs. Activity Monitor -> Disk Activity was saying like 4 MB / sec. – timpone Mar 14 '13 at 19:33
  • ok, this is wierd. Disk Active just shot up to ~ 30 MB / sec so crankin now (relatively speaking). I didn't change a thing on my end (although Dropbox was consuming a ridiculous CPU amount and I killed it). I am not sure if that would have been it though. – timpone Mar 14 '13 at 19:34
  • 1
    Remember that file sizes can cause changes in the speed you can copy at, loads of small files run slower than large files - there is the filesystem management overhead and the way files are sent in packets – Alain King Mar 14 '13 at 20:51

I would run a terminal command like iostat 5 and also run Activity Monitor to see if other processes are taking precedence to the copy and also inspect the volume of IO operations as well as the aggregate read/write bandwidth.

You could have a bottleneck on the drive that is sending the data, the CPU that is doing the copy or the drive that is receiving the data in addition to the raw bandwidth of the external drive's connection.

Also, check in system profiler under the USB tree to inspect that the device is actually negotiated a USB 2.0 connection.

Spinning HDD typically have a few hundred iops limit due to seek time even if there is perfect alignment of the data on the spindle so that the next block to be read is always directly under the read head when the drive schedules the next read. Other drive access, file fragmentation and other effects can often slow down a write to 50 iops or less which would clearly limit the transfer speed to 10 Mbps or less given typical block sizes for HFS+ filesystems.

In short, it might be a slow transfer due to the Mac or the drive sending the data and not a full or fragmented drive on the receiving end.

  • I think there was some contention with dropbox and possibly some buggy code for how they handle contention with mutexes – timpone Mar 14 '13 at 19:53
  • Could be - isolating the Mac from the network might also be a great way to ensure no syncing or other delays are happening. – bmike Mar 14 '13 at 20:06
  • Y, thx for answer - I think you covered most of the issues - appreciate it – timpone Mar 14 '13 at 20:09
  • sorry took awhile, some things came up – timpone Apr 24 '13 at 16:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .