Date: Sat, 23 May 2020 10:11:55 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 244356] Writing to a USB 3.0 stick is very slow Message-ID: <bug-244356-19105-yFePCCVCTz@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/> References: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244356 Gary Jennejohn <gljennjohn@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gljennjohn@gmail.com --- Comment #76 from Gary Jennejohn <gljennjohn@gmail.com> --- (In reply to Olivier Certner from comment #75) Flash is complicated. There's SLC (one bit per cell, fast but expensive), = MLC (two bits per cell), TLC (three bits per cell) and QLC (four bits per cell, high storage density but slow). The more bits per cell the more complicated it is for the controller to wri= te data to the flash. I tested with a 128GB USB3 stick from Medion. Probably not the fastest sti= ck on the market. I suspect, but can't prove, that this stick uses TLC flash. I must point out that I was using this stick for backups in a Linux project with the ext4 filesystem. The stick was pretty full. I then decided to reformat it with UFS. Note that after formatting there w= ere still lots of dirty sectors left over from using it for Linux backups. I mounted the stick and used dd to copy a 3GiB file with bs=3D128k to the U= FS file system. The average transfer rate was 3.95MiB/s. I then unmounted the stick to get rid of the file contents in the buffer ca= che and remounted it. Then I used dd with bs=3D128k to copy the file to /dev/null. The average transfer rate was 104.6MiB/s. So, I still suspect that the controller was forced to do lots of bookkeepin= g to copy data to the flash. Since flash is initialized with all 1s when manufactured and setting a 1 to= a 0 is easy for the controller, but setting a 0 to a 1 is much more time consum= ing, an interesting test would be to fill all sectors with 1s and then do a tran= sfer test. Unfortunately, there's no /dev/one available, so this would be rather challenging to do with a high-capacity stick. There may be a command which can be sent to the controller to erase all sec= tors at once (set all bits to 1), but I'm not sure about that. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244356-19105-yFePCCVCTz>