TRIM is accessible via "hdparm --trim-sector-ranges" on a USB device supporting ATA PASS THROUGH:
Device is an SSD in a USB 3.0 adapter identified in lshw as follows:
Bus 001 Device 005: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
Adapter is hosting a 180GB Intel 530 M.2 NGFF SSD
fstrim fails as described with "FITRIM ioctl failed: Operation not supported" even though the hdparm invocation works fine. I've tested full ext4 filesystem trims using wiper.sh, the utility by Mark Lord that was bundled for a while with hdparm until fstrim came out. This utility works by wrapping the hdparm invocation.
So it definitely seems to be the case that the USB driver stack is declining to implement TRIM even in cases where it is technically able to do so. Given the extremely high performance of USB3+, it seems very likely that USB-connected SSDs will become increasingly usual.
TRIM is accessible via "hdparm --trim- sector- ranges" on a USB device supporting ATA PASS THROUGH:
Device is an SSD in a USB 3.0 adapter identified in lshw as follows:
Bus 001 Device 005: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
Adapter is hosting a 180GB Intel 530 M.2 NGFF SSD
fstrim fails as described with "FITRIM ioctl failed: Operation not supported" even though the hdparm invocation works fine. I've tested full ext4 filesystem trims using wiper.sh, the utility by Mark Lord that was bundled for a while with hdparm until fstrim came out. This utility works by wrapping the hdparm invocation.
So it definitely seems to be the case that the USB driver stack is declining to implement TRIM even in cases where it is technically able to do so. Given the extremely high performance of USB3+, it seems very likely that USB-connected SSDs will become increasingly usual.