[SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

Blake Smith · 2024-04-11 15:18:16

Hello everyone, thank you for taking your time to read this, this is my first post here, apologies for my ignorance.

I have searched far and wide for a solution to this issue and I could not find anything, I have a Lexar USB 3.0 drive that I have formatted to ext4 and then encrypted it via luks in gnome-disks ran as sudo.

This issue bugged me, even after I had fully zeroed out the drive with zeroes, the issue was remedied slightly by quicker write speeds but still painfully slow read speeds, it takes some 30 seconds+ to be detected by gnome-disks and PCmanFM after I plug it in.

These are the read results from hdparm:

sudo hdparm -tT --direct /dev/sdc1

/dev/sdc1:
 Timing O_DIRECT cached reads:     4 MB in  2.93 seconds =   1.37 MB/sec
 Timing O_DIRECT disk reads:   6 MB in  3.84 seconds =   1.56 MB/sec

These are the results from gnome-disks:

 Disk or device: 62 GB Drive — Lexar USB Flash Drive [1100] (/dev/sdb)
Sample size: 4.0 MiB (4,194,304 bytes)
Average read rate: 151.3 kB/s (50 samples)
Average write rate: 2.0 MB/s (50 samples)
Average access time: 2.64 msec (500 samples)

I realize that gnome-disks isn't the most reliable and so I apologize.

Actual speeds seem to be around 1 MB/s read and (rsync) 50+ MB/s write.

Preferably, I would like to keep the USB drive encrypted but if formatting it is the only way then I don't mind.

Thank you all!

Last edited by Blake Smith (2024-04-22 14:33:21)

dakota · 2024-04-12 02:26:20

Are you sure it's a 3.0 drive?

What does dmesg say when you plug it in?

Cheers,

Blake Smith · 2024-04-12 09:16:18

Hello Dakota.

This is the output of dmesg:

[35585.366062] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[35585.383956] usb 4-1: New USB device found, idVendor=21c4, idProduct=0cd1, bcdDevice=11.00
[35585.383973] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[35585.383979] usb 4-1: Product: USB Flash Drive
[35585.383984] usb 4-1: Manufacturer: Lexar
[35585.383988] usb 4-1: SerialNumber: 0400000000058023
[35585.506262] usb-storage 4-1:1.0: USB Mass Storage device detected
[35585.506498] scsi host4: usb-storage 4-1:1.0
[35586.587831] scsi 4:0:0:0: Direct-Access     Lexar    USB Flash Drive  1100 PQ: 0 ANSI: 6
[35586.588116] sd 4:0:0:0: Attached scsi generic sg2 type 0
[35587.214449] sd 4:0:0:0: [sdb] 120832000 512-byte logical blocks: (61.9 GB/57.6 GiB)
[35587.215105] sd 4:0:0:0: [sdb] Write Protect is off
[35587.215107] sd 4:0:0:0: [sdb] Mode Sense: 43 00 00 00
[35587.215352] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[35588.529721]  sdb: sdb1
[35588.529913] sd 4:0:0:0: [sdb] Attached SCSI removable disk

Since it is using xhci_hcd, I believe that means it is USB 3.0, both the drive and the port are blue as well.

This is the output of lsusb -t just for extra measure:

/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 001: Dev 003, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

I don't understand what this means exactly but here's hoping this helps!

Thank you for your time!

seth · 2024-04-12 10:27:00

That's some usb key, right?
The fastest bus in the world won't help w/ slow drives and the throughput (hdparm doesn't care about ecryption or filesystem) is well below even USB 2.0 limits (40MB/s - though nb. that your OP has sdc and sdb… you might have tested another drive in hdparm?)

Does the drive perform any better when attached to another OS?
Mind you, writing to it will go through the cache, ie. you get very high performance initially (local read) and then it stalls when trying to clear the cache onto the actual device.

Blake Smith · 2024-04-12 21:45:17

Hello Seth, thank you for all your contributions to the Arch Linux community, you're a real gem!

I had Kali installed alongside Arch and so I tested it out in there and the results are even worse (understandably so, considering it's not bleeding edge).

What's intriguing to me is that the write speed is more than the read speed, I have a USB 2.0 thumb drive and reading files from it is somehow quicker than the USB 3.0 thumb drive, writing files to it is slower than the USB 3.0 but it reads much faster, I have no idea why.

Is this normal?

seth · 2024-04-12 22:13:46

No, the normal case is that reading is much faster, but because of the encryted filesystem the write might be skewed by some FS specific cache (let alone the VM cache that probaly explains the 50MB)

You have to perform those throughput tests avoiding any filesystem to measure the device performance, but running eg. https://wiki.archlinux.org/title/Benchmarking#dd on the device will shred the encryption and the filesystem and effectively all data on the key.

Another explanation is that you've a really slow CPU and en/decrypting isn't done in hardware because you picked an unfortunate algorithm, but
a) I don't believe that
b) "cryptsetup benchmark" and the direct read/write test would reveal this

Blake Smith · 2024-04-12 23:38:36

Hello Seth, thank you, these are the results from cryptsetup:

$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1411273 iterations per second for 256-bit key
PBKDF2-sha256    1842840 iterations per second for 256-bit key
PBKDF2-sha512    1315653 iterations per second for 256-bit key
PBKDF2-ripemd160  804122 iterations per second for 256-bit key
PBKDF2-whirlpool  553046 iterations per second for 256-bit key
argon2i       4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       616.9 MiB/s      2859.1 MiB/s
    serpent-cbc        128b        94.3 MiB/s       625.9 MiB/s
    twofish-cbc        128b       201.7 MiB/s       400.3 MiB/s
        aes-cbc        256b       542.8 MiB/s      2248.9 MiB/s
    serpent-cbc        256b        99.7 MiB/s       626.9 MiB/s
    twofish-cbc        256b       211.8 MiB/s       400.5 MiB/s
        aes-xts        256b      2559.8 MiB/s      2555.8 MiB/s
    serpent-xts        256b       575.3 MiB/s       566.8 MiB/s
    twofish-xts        256b       371.2 MiB/s       377.5 MiB/s
        aes-xts        512b      2008.8 MiB/s      2040.4 MiB/s
    serpent-xts        512b       583.4 MiB/s       568.4 MiB/s
    twofish-xts        512b       378.6 MiB/s       379.7 MiB/s

These are the results from dd, I know you told me not to do it but just in case, I decided to do it

$ dd if=/dev/zero of=~/USB bs=1M count=256 conv=fdatasync,notrunc status=progress
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 28.6378 s, 9.4 MB/s

I then ran

 
# echo 3 > /proc/sys/vm/drop_caches
$ dd if=tempfile of=/dev/null bs=1M count=1024 status=progress
268435456 bytes (268 MB, 256 MiB) copied, 252 s, 1.1 MB/s
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 252.267 s, 1.1 MB/s

Then I did this command around 5 times and the average result was 7 gigs

 $ dd if=tempfile of=/dev/null bs=1M count=1024 status=progress
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 0.0372259 s, 7.2 GB/s

I'm not sure what to make of this other than that I guess it is not a CPU issue?

Kind regards

seth · 2024-04-12 23:49:16

encryption isn't the bottleneck
"dd if=/dev/zero of=~/USB" writes zeros into a file "USB" in your $HOME directory, I don't assume that you're mounting the troublesome key as your $HOME?

"dd if=tempfile of=/dev/null" writes "tmpfile" from the $PWD (is that on the troublesome key?) into /dev/null - and w/o dropping caches that's gonna be insanely fast because the file is in the file cache (you#re measuring your RAM speed)

Please be very careful when invoking "dd", there're absolutely no safeguards - if you put the wrong thing behind "of=" you can shred your system.

Blake Smith · 2024-04-13 12:54:20

Hello Seth, thank you again!

seth wrote:

"dd if=tempfile of=/dev/null" writes "tmpfile" from the $PWD (is that on the troublesome key?) into /dev/null - and w/o dropping caches that's gonna be insanely fast because the file is in the file cache (you#re measuring your RAM speed)

Yes, I mounted the drive in my home folder and CD'ed into it in the later tests, I should've specified, apologies.

seth wrote:

Please be very careful when invoking "dd", there're absolutely no safeguards - if you put the wrong thing behind "of=" you can shred your system.

Thank you for the advice, this is one of the rare times I touch dd because it's scary

It seems as though there is nothing we can do?

Kind regards

seth · 2024-04-13 13:22:06

You can test the raw device read/write speed, but that means to bypass and invalidate the filesystem.
But it seems the key is just slow (is it old?)

Blake Smith · 2024-04-18 23:46:19

Hello Seth, apologies for the very late reply.

The USB drive is new, I bought it around three weeks ago. After that, I formatted it from it's original filesystem (NTFS or FAT, maybe?) to ext4 so I can encrypt it with luks.

The manual that was inside of the USB drive's folder was corrupted I believe, I cannot believe how I didn't realize that something fishy was afoot earlier.

Apologies for wasting your time, it seems as though I bought a defective USB drive without realizing, seems like there is nothing we can do! Too bad I can't return it as I bought it physically and threw away the receipt.

Will mark as solved.

Arch Linux

#1 2024-04-11 15:18:16

[SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#2 2024-04-12 02:26:20

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#3 2024-04-12 09:16:18

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#4 2024-04-12 10:27:00

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#5 2024-04-12 21:45:17

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#6 2024-04-12 22:13:46

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#7 2024-04-12 23:38:36

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#8 2024-04-12 23:49:16

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#9 2024-04-13 12:54:20

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#10 2024-04-13 13:22:06

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

#11 2024-04-18 23:46:19

Re: [SOLVED] USB 3.0 fast write speeds but painfully read slow speeds

Board footer