USB 3.0 pendrive

#21

Here is a raw read using dd of my 3tb drive inside the enclosure. As you can see, the speed looks good for this old spinner. However, real life usage is a different story.

rock@RockSvr:~$ sudo dd if=/dev/sda of=/dev/null bs=100M
^C32+0 records in
31+0 records out
3250585600 bytes (3.3 GB, 3.0 GiB) copied, 25.6378 s, 127 MB/s
rock@RockSvr:~$

#22

I’ve run modprobe uas, also added uas to /etc/modules, put the pendrive in lower USB 3.0 port and restarted the board. lsmod gives that uas is loaded. I have script:

#!/usr/bin/env bash
echo === WRITE 1GiB ===
echo -n "sync..." ; sync ; echo "ok"
time {
        dd if=/dev/zero of=temp conv=fdatasync bs=1024k count=1k
        echo -n sync...
        sync
        echo ok
}
rm -f temp
echo -n "sync..." ; sync ; echo "ok"
echo Done.

which now gives:

=== WRITE 1GiB ===
sync...ok
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 35,9079 s, 29,9 MB/s
sync...ok

real    0m35,940s
user    0m0,000s
sys     0m6,064s
sync...ok
Done.

Surely the pendrive achieves higher speeds on PC. However I don’t know much about this pendrive (chip, controller etc.).

EDIT: Just tested HDD in USB 3.1 enclosure. Acts up to 26.4 MB/s. On PC full write speed is about 120 MB/s.

#23

Wow, you’re facing worse results than I am. What do you get when you run hdparm?

#24 
Timing buffered disk reads: 198 MB in  3.03 seconds =  65.45 MB/sec

That’s really strange, because it says that pendrive is in USB 3.0 mode at this speed. Should give about 140 MB/s read and 80-90 MB/s write…

#25

While HDD write is up to 26.4 MB/s, reading is blazing fast! I’ve got over 124 MB/s constant read speed. Still pendrives are too slow…

#26

Just thought I would add my unusual experience that may shed some light on a possible issue.
I have done quite a bit of speed testing (fio) with my Samsung EVO 970 250GB NVMe and for what ever reason after some random amount of testing the speeds drop by about 70% and nothing I do restores it. I have no explanation why this happens but formatting the drive fixes the speed problem. Drive is formatted with ext4.

Maybe you are having a similar issue?

#27

I tried using the Debian image yesterday, and I see the same results. The speed is just too slow for my needs. Such a bummer.

#28

Same thing, too slow for my needs now

#29

I just got these numbers on my 970 EVO Plus 250Gb, Rockpi4 V1.4 4GbRAM
1.3 GBps read
382 MBps write
Dangg:D

#30

Ok, so first off, that device you are referring to is M2. This thread is about USB3.
And second, 1.3 Gbps is only 162.5 MB/s, and 382 Mbps is only 47.75 MB/s… this is eMMC territory. I’m seeing people displaying MUCH better results from USB3 devices in this thread. Despite the “:D” you share on your post, you certainly don’t have anything to smile about.

#31

Its not for “whatever reason”. There is a VERY SPECIFIC reason why this happens. You can’t re-write to previously written blocks on a solid state storage device until those blocks have been wiped clean. The reason why it is much slower is because of the time it takes to wipe those previously used blocks.

Two easy solutions;

  1. Manually run fstrim on the filesystem:
# fstrim -v /mount/point
  1. automatically, by mounting the filesystem with the “discard” option.

Now this is the key to the process; the DRIVE can’t just trim itself, because after a block has been written to, it has no way to know if it is still in use or is available. That means that the OS has to TELL it what blocks are available and should be trimmed. The OS queries the filesystem, which tracks what is and is not in use, and sends the results to the disk, which should do the job in the background, rather than you actually having to wait for the whole disk to write over.

When you’re FORMATTING a disk, it issues a trim command for the entire, CONTIGUOUS, region that will be occupied by the new filesystem (typically the entire partition). Now formatting your disk just to trim it is, of course, very wasteful – both in terms of the longevity of the disk itself, as well as the work it takes to return the disk to the state it was in. My advice to you would be to mount the filesystem using the discard option, and then occasionally check with the fstrim command to make sure. This will optimize the disk performance without unduly hurting its longevity. After all, blocks need to be wiped prior to being rewritten anyway, might as well do it proactively.

Edit: one of the reasons why the discard mount option is so powerful, is because it has basically zero overhead. When you delete a file, that fact is recorded in the filesystem as an unlink. On a magnetic disk, that is ALL that happens, whatever data was pointed to by the inode that was just erased ends up being “lost” somewhere on the drive. Same happens without the discard option, which means that in order for the fstrim command to work, it has to run through the entire filesystem in order to track down all the blocks that are IN USE, and then invert that selection before feeding the results to the disk for a trim. So if you run the fstrim command, it can actually take quite a while sometimes. But if you mount with discard, then before unlinking, it takes the list of blocks from the inode RIGHT THEN and sends it to the disk to be trimmed. No need to search for it later.

1 Like
FSTRIM is not working for SSD + Quad SATA Hat