Good call… I assumed it would be okay as the errors were on read (not write)… but confirmed okay…
e2fsck 1.47.3 (8-Jul-2025)
SteamLibrary: clean, 248982/125026304 files, 268307999/500099328 blocks
======== SOLUTION ========
Some interesting update posts that ended up having nothing to do with the solution
Update: a post I read at https://forum.odroid.com/viewtopic.php?t=39566 suggests a possible reason/answer…
This also depends on the kernel version. Certain USB enclosures are buggy and are/should be blocked for UAS for stability, so if for example a newer kernel blocks UAS for a specific model there may be a good reason for it…
I block uas via a long usb-storage.quirks=… options line for all my Seagate Backup Plus externals
And I guess I found one of the drives with a buggy enclosure… at any rate, if it performs well with the older driver, I’ll be okay with it.
=========
Update 2: https://www.rshtech.com/blog/common-problems-in-the-use-of-usap-5 suggests a better explanation than “buggy enclosure”…
UASP (USB Attached SCSI Protocol) replaced the BOT (Bulk-Only Transfer), and requires 3 things…
- The USB controller on your computer needs to support UASP.
To check if Linux is using UASP or BOT, run
Isusb -tand look for “driver = uas” instead of “driver = usb-storage”
- Your USB 3.0 device supports UASP.
- Your computer has installed the correct driver.
It’s possible that the drive/enclosure (despite being USB3) does not fully support UASP (bi-directional data transfer)… I checked for firmware updates, but none were reported.
I’m also using kernel 6.18… I suppose I could see if kernel 6.12 behaves any different in case this is a kernel/driver issue.
=======
Update 3: [SOLVED] How to check UASP support? / Kernel & Hardware / Arch Linux Forums offers a bit more information and mentions that some chips/tech were created before UASP was fully standardized… so some “early adopter” components may not work and/or meet the final specification.
Windows and Linux enable UAS on any USB controller that isn’t blacklisted. The Asmedia ASM1042 was the only chip for which Windows 7 support could be found and is now blacklisted by all OS due to chip bugs so Windows 7 does not support UASP.
To get UASP you need 3 components.
- OS Support: Windows 8, Windows 10, Linux
- USB controller support: Any USB 2 or 3+ interface that doesn’t have UASP blacklisted.
- UASP ready peripherals: UASP standards solidified near the end of USB 3.0 development so most USB 3.0 storage products are not UASP compatible. Some buggy chips were produced so some products claiming UASP support have been blacklisted. Hopefully most USB 3.1 products will include UASP support.
My disk supports USB 3.2 … but i guess that doesn’t mean it fully supports UASP.
I started looking for similar issues/solutions that may also be related to my Framework 16 Laptop and found Framework 16 USB Confusion - Community Support - Framework Community which revealed (reminded me?) that not all module ports are created equally (especially around power delivery)… and using a “higher” powered port allows for some devices to work that didn’t when connected to lower powered ones.
Expansion Card Slot functionality on Framework Laptop 16 (AMD Ryzen™ 7040 Series) states that…
Ports 1,2,4,5 are shared on a first come first serve basis. So they are 1.5A by default, but one port from any of these can negotiate 3A over PD. Once that is taken, the other ports are limited to 1.5A. Ports 3,6 are 900mA.
Hmm, so 2 ports are low (900mA) powered and so I thought I’d be a really fast confirmation if I tested the 1,5A ports with my new cell phone that I’d recently reported an issue about… Kernel errors connecting newer android cell via USB-A to C - #4 by Daniel-I … and connecting it to a non-port 3 or 6 port (900 mA) yielded a working connection, and a phone that prompted for debugging mode! Well hurray for learning about avoiding low powered ports.
And guess which port my new external SSD is connected to? yep, on the port 3,6 (900 mA) line.
So I:
- shutdown Steam
- safely ejected the drive
- unplugged the drive
- undid the “quick” quirk
$ su
# echo "" > /sys/module/usb_storage/parameters/quirks
# cat /sys/module/usb_storage/parameters/quirks
# exit
- shuffled my mouse and controller down to fill ports 3 & 6
- reconnected the drive to a 1.5A port and confirmed UASP mode
$ lsusb -t
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 007, If 0, Class=Mass Storage, Driver=uas, 10000M
- mounted the drive
- started Steam
- played a full Crucible run in No Rest for the Wicked for ~20 min and Cyberpunk for ~40 min without any issues!
So the lesson learned is… know your hardware’s requirements, capabilities, and limitations… and ensure devices that need full power are connected on a port that can deliver it.
Update: No errors the next morning in the journal… so backup ran smoothly as well… all issues experienced seem to be resolved by choosing the properly powered port with a USB module for my FW16.