How to Fix Unreliable USB Hard Drives, Stalled Transfers in Linux

Last June, I reviewed a Ryzen Embedded SBC with Windows 10, and the USB hard drive I normally use for review had all sorts of problems including very slow speeds and/or stalled transfers but no error messages.

Last week, I tried again by installing Ubuntu 20.04 on the same Ryzen Embedded SBC, and the USB hard drive had troubles again, so just assume there were some hardware incompatibility issues between the SBC and the drive, and there may not be a fix or workaround.

Sometimes, it’s indeed a hardware issue with the drive getting too many bad blocks, and if that’s the case, and the drive is still under warranty you can return it and get a fresh new (or refurbished) drive for free. But that drive was still working with my laptop getting around 100MB/s.

So I ran out of ideas until numero53 commented he had similar problems with many USB-SATA adapters, and the trick was to disable UAS (USB Attached SCSI) which in theory you’d want to improve performance. The problem was reported by Raspberry Pi and ODROID users, and you’d normally get error messages that look like that:


I did not have any such messages, but I still tried to disable UAS on this particular drive with little conviction it would work. First, we’ll need to find the USB VID/PID for the adapter:


Now we can create a file to blacklist the drive/adapter in order to prevent the UAS module to load for this drive:


After a reboot, we can see the drive was blacklisted:


Let’s see if that fixed my issue by running iozone storage benchmark:


It could write a  1GB file at about 90+MB/s. Pretty much normal on this drive. Issue fixed! The ~2GB/s read numbers are clearly influenced by the cache…

It’s apparently quite a common problem with Seagate (VID: 0x0bc2) and Western Digital (VID: 0x1058) USB drives, and Thomas Kaiser just blacklisted all such drives in Armbian by default a few years ago.

OK, so we’ve found a workaround in Linux/Ubuntu. But what about Windows 10, since I got the same problem here. There’s no obvious solution that I could find. There’s uaspstor.sys file in the %WinDir%\System32\drivers folder that is the USB Attached SCSI (UAS) Driver for Windows 10. But it’s not used directly by my drive.

Click to Enlarge

I suppose it might be possible to try to move/rename drivers’ files until the issue is solved, but it’s not ideal since other drives that actually work properly with UAS would also be affected. I looked for methods to blacklist UAS for specific drivers in Windows 10 just like we just did in Linux, but there doesn’t seem to be any solution. If you do have a workaround, please do share.

Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.

Support CNX Software - Donate via PayPal, become a Patron on Patreon, or buy review samples
Subscribe
Notify of
guest
12 Comments
oldest
newest most voted
tkaiser
tkaiser
1 month ago

> The ~200MB/s read numbers must be influenced by the cache…

In fact it’s 1.9GB/s (1916998kB) and this is most probably due to your filesystem being exFAT handled by FUSE and all FUSE filesystems avoiding direct I/O so filesystem benchmarks show usually how fast the OS can read from the filesystem cache. The following call shows more realistic numbers:

domih
domih
1 month ago

On Odroid H2, N2, N2+ and C4, using: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 I see in most cases UAS to be slower than BOT in the reclen ranges of 16k, 512k, 1024k using SSDs or HDDs. Ubuntu 18.04 or 20.04. I started to systematically do these tests when I discovered that a cassandra-stress tool session was running about 5% faster with BOT compared to UAS. So this is not specific to a iozone methodology. So while there are plenty of cases where UAS… Read more »

tkaiser
tkaiser
1 month ago

> I see in most cases UAS to be slower than BOT

With a huge variation of different USB-to-SATA bridges or just a few or even one?

domih
domih
1 month ago

(1) USB SATA Bridge from Hard Kernel: Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp.

(2) USB SATA Bridge from NexStar external enclosure: Bus 002 Device 004: ID 174c:1351 ASMedia Technology Inc. USB3.0 Hub

domih
domih
1 month ago

Longer answer (could no longer edit the previous post) USB SATA Bridge from Hard Kernel: Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. USB SATA Bridge from NexStar external enclosure: Bus 002 Device 004: ID 174c:1351 ASMedia Technology Inc. USB3.0 Hub If you know of external enclosures with chipset not showing this behavior, I’m all ear and ready to buy it or them for testing. I tested two SSD and two HDD: WD 3D Blue 1 TB Crucial MX500 1 TB WD Red 4 TB (the CMR one, not the SMR) Seagate IronWolf 8TB… Read more »

tkaiser
tkaiser
1 month ago

Not talking about your results (too hard to read without proper formatting and without being able to look at raw data usually not worth the efforts anyway) but about methodology. If you don’t control what’s going on in the background you’re just generating numbers without meaning. I always run at least sbc-bench -m (monitoring mode) in parallel when doing any sort of benchmarking and afterwards I always check dmesg output for anomalies (like e.g. bus resets or similar stuff). Especially cheap consumer SSDs implement write caches and once this capacity is exceeded they get dog slow (I measured below 60… Read more »

domih
domih
8 days ago

If you click on Read More, the formatting is clear enough. I understand what you mean… BUT I’m not trying to reach a state of pure synthetic benchmark to compare X vs. Y. I’d rather want to see what mode is best in regular production environment. If during a synthetic benchmark X is better than Y, fine. But if this is never going to happen in production, all the synthetic benchmarks of the world are useless to me. The reason I started to test UAS vs BOT is because my DB app was running faster with BOT compared to UAS.… Read more »

Icenowy Zheng
Icenowy Zheng
1 month ago

Disassemble the disk and check out what chip is used?

tkaiser
tkaiser
1 month ago

Older Seagate USB3 disks use an ASMedia ASM1053, since end of 2014 ASM1153 or JMicron JMS577. But regardless of the chip the firmware is the problem since it’s never ASMedia’s or JMicron’s standard firmware.

clort81
clort81
28 days ago

Defective by Seagate.

clort81
clort81
28 days ago

I read this was a faulty implementation of SATA over USB by Seagate, but my memory is bad.

This is a super annoying problem and disabling UAS didn’t fix for my current seagates that i need to access.

Had to buy a damn laptop for them.

Advertisements