2

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 /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 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 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.

Questions

  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.

Improve this question

1 Answer 1

Reset to default
1

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
Improve this answer
12
  • 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 Commented Mar 5, 2021 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? Commented Mar 5, 2021 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. Commented Mar 5, 2021 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 Commented Mar 5, 2021 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. Commented Mar 5, 2021 at 21:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.