Disclaimer: I know there's Raspberry Pi community here, but I don't think it's Pi-specific, more like Raspbian (or Debian?) vs USB HDD vs NTFS, etc.

TL;DR: So, I've got a Raspberry Pi 4 with an external USB HDD. Read/write speeds there are quite low, and the most surprising thing for me is that read is actually slower than write! So how could it be and where's the culprit?

In details:

  • OS
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux
  • fstab:
UUID=1276F80376F7E57F  /mnt/usb_hdd    ntfs-3g    defaults,big_writes,noatime   0   0
  • hdparm test
pi@raspberrypi:~ $ sudo hdparm -tT /dev/sda

 Timing cached reads:   1496 MB in  2.00 seconds = 747.81 MB/sec
 Timing buffered disk reads: 258 MB in  3.01 seconds =  85.60 MB/sec
  • rsync read
pi@raspberrypi:~ $ rsync --progress -hv /mnt/usb_hdd/Share/Downloads/Games/Civ5.iso ~/Civ5.iso
          2.37G 100%   18.90MB/s    0:01:59 (xfr#1, to-chk=0/1)

sent 2.37G bytes  received 35 bytes  19.19M bytes/sec
total size is 2.37G  speedup is 1.00

The strange thing is, it starts with ~70MB/s, but almost iimediately drops to ~20 and then deviates between 8 and 25. Very unstable.

  • rsync write
pi@raspberrypi:~ $ rsync --progress -hv ~/Civ5.iso /mnt/usb_hdd/Share/Downloads/Civ5.iso
          2.37G 100%   39.15MB/s    0:00:57 (xfr#1, to-chk=0/1)

sent 2.37G bytes  received 35 bytes  40.52M bytes/sec
total size is 2.37G  speedup is 1.00

This one also starts with ~65MB/s, but gradually slows to ~35. At least not that random as read.


  1. Aren't both read and write slow in general? Even considering Pi and NTFS - 40MB/s is kind of slow, isn't it? If so - where it the problem?
  2. Why is read slower than write?? And why is read speed so unstable over time?

CPU is at ~30% during transfer and there's plenty of memory... Is it "just NTFS"?
Anyway I'll appreciate any help here.


To answer your first question, 40MB/s sounds like a bottleneck with USB 2.0. The Pi 4 supports USB 3, but ensure your HDD and cable are USB 3.

Updated with information from the comments:

Also note that your rsync involves 2 sides: external HDD and wherever your home is. To remove the second part from the equation try dd for just-HDD benchmarking:

  • Writing involving filesystem: sudo dd if=/dev/zero of=/mnt/usb_hdd/blob bs=16M count=100 status=progress oflag=direct
  • Reading from a filesystem: sudo dd if=/mnt/usb_hdd/blob of=/dev/null bs=16M count=100 status=progress
  • Reading straight from a disk: sudo dd if=/dev/sda of=/dev/null bs=16M count=100 status=progress iflag=direct
  • The HDD is actually a normal laptop HDD in a brand new USB enclosure that promised to support USB 3.0+. I'm pretty sure it does, but how do I make sure? Anyway, here's result of sudo lsusb -D /dev/bus/usb/002/002 for it: pastebin.com/gTHjLgMt – FlasH from Ru Mar 5 at 21:16
  • @FlasHfromRu yeah, it does appear to be supporting USB 3.0 (look towards the bottom, 5Gbps). Do you get normal read/write speeds on a Windows machine? – Chris Mar 5 at 21:20
  • @FlasHfromRu One other thing to check, make sure you've plugged the Pi into one of its USB 3 ports (the blue ones). Not all of them are USB 3. I doubt this is the problem given it detected the device supports USB 3 speeds, though. – Chris Mar 5 at 21:23
  • 1
    One more thing I would try is to rule out if the bottleneck is filesystem or caching related using the dd utility. This command will DESTROY the data on the HDD so make sure it's backed up or use a different harddrive with unimportant data. Again, this test will destroy the data on the harddrive. dd if=/dev/zero of=/dev/yourhdd bs=16M count=100 status=progress oflag=direct – Chris Mar 5 at 21:29
  • 1
    Ok. The dd command I gave you is for a write test. A read test (nondestructive) would be done by the following: dd if=/dev/yourhdd of=/dev/null bs=16M count=100 status=progress iflag=direct" I probably should have given the nondestructive read test first.... Just make sure "of=/dev/null" for this read test and it won't be destructive. – Chris Mar 5 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.