Various USB HDD Speed issue

Creating an issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
    G_LIVE_PATCH_STATUS[0]=‘not applicable’
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye 0
  • Kernel version | uname -a
    Linux Syncthing1 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | dpkg --print-architecture
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    RPi 4 Model B (aarch64)
  • Power supply used | (EG: 5V 1A RAVpower)
    3.0 A Original Raspi Foundation PSU
  • SD card used | (EG: SanDisk ultra)

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
    not really a software title issue imho, but e.g. Nextcloud, Urbackup, Syncthing
  • Was the software title installed freshly or updated/migrated?
    Yes, Urbackup
  • Can this issue be replicated on a fresh installation of DietPi?
    Well - not really…
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. Start reading writing anything to or from an external Western Digital HDD

Expected behaviour

  • Write read and write speeds of ~70-100 MB/s of sequential read/write speed

Actual behaviour

-2-4 MB/s of sequential write speed

Extra details

-I have the exact same issue on 3 identical dietpi installations which are almost 100% identical in terms of hard- and software. 2 of them are running at my sister-in-law’s place one is running in my own home. The issue is not persistent. Sometimes i recovers for a couple of minutes.
I had the filesystem unmounted and checked - no issues. It contains the dietpi_userdata because it has to. I am using nextcloud and nextcloud stores its userdata underneath dietpi_userdata. And since i dont want to use a terabyte SD card… I checked the filesystem by shutting the system down, plugged the hdd into another server, mounted it and performed the check.
I can confirm that it ran quite fine on the other server. It seemed also to work fine when forcibly unmounting the drive and mounting it to a different mount point.
I am running into issues like these every now and then. E.g. i have a NUC9i9QNX here which has plenty of USB ports. I added a lot of USB 3.5 inch drives to it (with additional PSUs). And all of them work fine most of the time… Like 150-300 MB/s R/W speeds. Only one drive does 20-30 MB/s read speeds. While the rest if working fine. Of course i unmounted and checked the drive, used another USB Port etc… none of that worked. Only changing the mountpoint seems to solve it for a while. However - having to work with 2-4 MB/s R/W speeds at the above mentioned raspi installation is a showstopper. Please help me mitigating it.

[EDIT] Forgot to mention: i already omitted the the external harddrive from /etc/fstab and added it manually again (without using dietpi-drive_manager). That also changed nothing [/EDIT]

Does it help to disable APM via:

hdparm -B 254 /dev/sda

This usually prevents spindown on idle, but some HDDs react differently on APM levels.

Does the HDD perform better in RPi OS? If not, probably UAS is causing issues with these drives. Try to disable it:

echo 'blacklist uas' > /etc/modprobe.d/disable-uas.conf
1 Like

Thank you for that!
I disabled APM like you said and the last dietpi FS benchmark says (with a 10 GB Testfile):
103 MiB/s write
111 MiB/s read

lets wait for a day or two if these results are persistent - but it looks (very) promising so far…

i just also tried this for the other two installaions - with similar positive results :slight_smile:

1 Like

Great. I remember another case with an SSD which as well was very slow with reduced APM level. Looks like we should add the option to dietpi-drive_manager to adjust spindown timeout and APM level separately + describing the possible impact. Nasty that drives behave some inconsistently.