Copying data to a USB external drive is much slower than expected.

I have a 6TB external RAID drive that holds my photos, and I'm trying to do an archive copy of this data to another external USB drive.

Both are HDD drives, formatted with HFS+. I have turned off the Spotlight indexing for both drives. I'm using a MacBookPro with fast USB-C ports, and USB 3.0 or better ports on both external drives. All cables are 3.0 (SS) cables or better.

The file transfer started at about 200MB/s then slowed to around 20MB/s and sometimes even less. I'm using the Activity Monitor - Disk to display the read/write speed.

I think the initial transfer speed was the write buffers on the target drive filling up. I'm expecting a real-life transfer speed for USB 3.0 to be around 100MB/s.

Any idea why this is running so slowly. How can I figure out the bottleneck?


  • For testing, what happens when you copy something from your internal disk onto those drives? Are speeds ok? You could try BMD disk speed test as well: apps.apple.com/de/app/blackmagic-disk-speed-test/….
    – X_841
    Mar 29, 2021 at 9:27
  • Can you just use dd from the terminal to create a temp file and see what the raw speed is? dd if=/dev/zero of=/path/to/destDisk/temp.file bs=1000000000 count=1 will create a big file of 0's .. and give you a bytes/second. That's pretty much the fastest it can work on that drive. If it's good, try the NAS and see what it can sustain ...
    – Mr R
    Mar 29, 2021 at 11:56
  • The speeds are OK for a while, and in fact seems intermittent. I did a relatively large copy of 41GB and it was running at about 175MB/s, which is fine. Then it slowed to 2MB/s, which is almost stopped. I terminated the copy at that point to isolate where it was working. I then copied that smaller directory of only 85MB and it was again slow (5MB/s), but coping the same directory to a new target directory was fine (150MB/s)
    – Jim Leask
    Mar 29, 2021 at 16:57
  • @MrR using dd to my target drive gives 168937749 bytes/sec (169MB/s). Writing to the source RAID drive gives 125775058 bytes/sec (125MB/s). Note though we are reading from the second, which this didn't measure, but I think the transfer is fine. The above numbers are consistent with what I expect, and get for much of the copy until I hit the slowdown.
    – Jim Leask
    Mar 29, 2021 at 17:16
  • @JimLeask when the performance slows which disk is the blocker? Perhaps iostat might give a clue ??
    – Mr R
    Mar 29, 2021 at 21:14

2 Answers 2


Assuming there is no fault with any hardware or software, the following are some of the major factors that can contribute to a copy speed proceeding slower than the maximum transfer speed that a hard drive is capable of:

  1. Copying large numbers of small files with a single-threaded copying process... The overhead of simply opening each file for reading and creating each file for writing plus updating the HFS+ file system metadata takes extra time, which can slow single-threaded copy processes like drag-and-drop in the Finder considerably from this extra file system overhead. Some utilities such as the command-line tool rsync can speed up this process by pre-fetching files into its own memory buffer then writing the files to the destination drive from this buffer, thereby reducing the effect somewhat. Some third-party tools such as SuperDuper!, Beyond Compare, and others also perform some of this buffering to try and speed the file copy process but regardless of the utility used, copying large numbers of small files will naturally result in a lower overall throughput than if large files were being copied, due to this extra file system overhead.
  2. Copying large files from a hard drive with a severely fragmented file system... Copying at the file-level will open the file on the source drive then copy that file from beginning-to-end to the destination drive, but the file may not be stored contiguously on the source hard drive. In that case, the hard drive read-write head may have to seek to many different areas of the disk in order to read the file in-order, slowing file transfer considerably. This is more common for files that have changed a lot on disk over the years, and not so much for archival files that were created on the drive once then left (like photos) so this is probably not the case here.
  3. Copying files from a newer shingled-magnetic-recording (SMR) hard drive... The newest SMR hard drives cannot directly read the area on the drive that the HFS+ file system says contains the file. It must first read an entire track all the way around the disk, then pull out the portion of the data from that track that contains the file data that was requested. This is especially detrimental to copy speed as it mimics the above "fragmented hard drive" example, except it ensures that nearly every file behaves as if it is "fragmented" so unless you are copying the files off of the drive in the exact same order that they were all created, you will encounter severe slow down in copy speed. This is especially common among the largest low-cost external USB drives available today.
  • I think the hardware is fine. I wonder if #1 could be involved though. I did a new test today of 41GB, but stopped the copy when I noticed the speed dropped to 2MB/s. At that point approximately 15,000 files had been copied. I then copied the subdirectory where it was working earlier, and it was initially also very slow, but copying the same directory a second time and the speed was back to normal. Could a terminal copy help instead of using finder? I have not used rsync but it looks like it is for a different purpose than a simple copy.
    – Jim Leask
    Mar 29, 2021 at 17:27
  • @JimLeask there might be another factor going on too - do you have lots of files in the 1 directory - see this answer on HFS performance superuser.com/a/845156
    – Mr R
    Mar 29, 2021 at 19:18
  • @MrR No, the directories don't have a lot of files. Most are in the order of 20-50, with maybe the max at 200. I'm copying a large directory structure though and the complete directory has many thousand in the hierarchy. It always seem to start out fine, then slow down to a crawl. (running at 10MB/s at the moment)
    – Jim Leask
    Mar 29, 2021 at 19:35
  • Based on your 41GB test, the avg. file size is ~2.7MB, which is considered relatively large compared to the max transfer speed of ~100MB/s (just ~40 files/sec transferred, assuming files of similar size, which adds a relatively short amount of time for filesystem overhead). However, that you got different speeds when copying the same directory at different times without any other activity on the disk indicates indeed some hardware problem. Likely transient HDD read errors or USB resync errors. BTW- rsync is designed to do exactly this type of work, either local or over the network. Mar 29, 2021 at 19:57
  • @DaveJohnson Yes, many files are approximately 3BM (older photos). Right now, iostat shows it running for ~5 minutes at about 50MB/s, then a drop to 8MB/s, then back to 50 again. The Activity Monitor - Disk can show almost anything at any point in time even when the average from iostat is 50. I wonder if there is write cache or some admin task that is occasionally run, causing the pause in the transfer.
    – Jim Leask
    Mar 29, 2021 at 22:15

Can use iostat to debug / watch the performance over time - e.g. (summarise over 30 second intervals)

# iostat 30
              disk0               disk2       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
   24.73    8  0.20    30.90    0  0.00  10  7 82  1.40 1.67 2.02
    5.54  935  5.06     0.00    0  0.00  13 20 67  1.48 1.68 2.02
   10.44  594  6.06     0.00    0  0.00  16 22 62  1.49 1.67 2.01

You just need to check which is which .. e.g. (I have an internal SSD and an external spindle)

# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD — Data     112.4 GB   disk1s1
   2:                APFS Volume Preboot                 91.6 MB    disk1s2
   3:                APFS Volume Recovery                529.0 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4
   5:                APFS Volume Macintosh HD            11.3 GB    disk1s5

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS BACKUP                  3.0 TB     disk2s2
  • disk0 = Internal SSD disk1 = Source RAID disk2 = Target USB disk0 disk2 disk3 cpu load average KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m 10.54 43 0.45 477.50 34 15.68 924.43 18 15.83 1 3 95 1.11 0.87 0.77 8.19 95 0.76 490.79 137 65.67 948.18 71 65.58 2 4 94 1.00 0.86 0.77 12.78 34 0.42 486.87 78 37.11 948.77 40 37.27 2 4 95 0.94 0.86 0.77 14.76 25 0.35 492.04 71 34.30 950.97 37 34.36 2 4 95 0.91 0.85 0.77
    – Jim Leask
    Mar 29, 2021 at 21:41
  • Formatting didn't work above. It seems the transfer is being written at a rate of 30-50MB/s, when averaged over 30 seconds. Is the Activity Monitor - Disk showing an instantaneous readout? If so, it may have just been misleading as the iostat average isn't showing the dropout, although occasionally there is a 30 second average of just 3MB/s on both source and target disk.
    – Jim Leask
    Mar 29, 2021 at 21:53
  • @JimLeask if it works fast for 10 seconds, then doesn't for 20 the average might still be 30-50 ... what's more important is if you watch the transfer for as long as it was taking before before failure (10-15? minutes) and it doesn't drop, then it probably is going to work - just at that sort of rate ... so how much data are you transferring (e.g. 1TB @ 30MBps is going to be something like 9-10 hours ...)...
    – Mr R
    Mar 29, 2021 at 22:01
  • And can use longer "averaging" interval - 60s (or 120s) if waiting that long - less data to eyeball...
    – Mr R
    Mar 29, 2021 at 22:05
  • I'm transferring 4TB. I was expecting somewhere around 200MB/s, so 30 is almost a factor of 10 slower, turning a few hours into days. Perhaps this is what it is though given the file types. I think using rsync may be a better option though, as it also helps track the changes without having to manually check directories for changes.
    – Jim Leask
    Mar 30, 2021 at 0:07

You must log in to answer this question.

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