No TRIM via USB

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1336541/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1336541

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-utopic/

Hi, provide my study here :-)

As far as I can see to support TRIM via USB bridge the USB bridge chip MUST support SCSI / ATA Translation(SAT)'s ATA PASS THROUGH command in order to pass the TRIM command to the disk.

Reading drive's S.M.A.R.T. data is similar to TRIM which they both require working ATA PASS THROUGH command, you may checkout following webpages for more info:

* [USB – smartmontools](https://www.smartmontools.org/wiki/USB)
* [Supported_USB-Devices – smartmontools](https://www.smartmontools.org/wiki/Supported_USB-Devices)

and YES, external HDD closure's controller may not provide this functionality, make sure to checkout the chip's datasheet before purchasing any new one(while some may support this functionality via controller firmware upgrade most of them don't)

However even you can read S.M.A.R.T. data using smartmontools utility, TRIM is still (currently) not possible for unknown reason, might be the usb-storage kernel module issue I guess.

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.

Correction to the above, that's the lsusb identification of the adapter. lshw identifies it as

     *-scsi
          physical id: 1
          bus info: usb@1:2.4
          logical name: scsi0
        *-disk
             description: SCSI Disk
             product: 2115
             vendor: ASMT
             physical id: 0.0.0
             bus info: scsi@0:0.0.0
             logical name: /dev/sda
             version: 0
             serial: 00000000000000000000
             size: 167GiB (180GB)
             capabilities: gpt-1.00 partitioned partitioned:gpt
             configuration: ansiversion=6 guid=0c8c6c54-9b77-45eb-ac02-39017ab4e289 sectorsize=512

It seems that if the device is handled by the usb-storage driver, TRIM is as of this writing unsupported and likely to remain so.

usb/storage/scsiglue.c sets skip_vpd_pages to true,
source/drivers/scsi/sd.c will not query for the necessary block limits to support discard if skip_vpd_pages is true.

The bug poster should note per comment #1 in their dmesg excerpt that their device is using the usb-storage driver

However, my Intel 530 SSD in the ASMT 2115 enclosure is acquired by the uas driver rather than usb-storage. TRIM is not supported there, possibly because of a failing in the bridge controller's translation of the SCSI unmap method to ATA TRIM.

hdparm (and presumably blkdiscard, which I haven't tried) succeed because they use ATA commands directly without going through a SCSI translation layer either in usb-storage (disabled) or in the enclosure firmware (possibly broken?).

The ASMedia bridges (as of the USB 3.1 Gen 2 ASM1351) simply does NOT have UNMAP->TRIM implemented at all. It does support the "ATA PASSTHROUGH" SCSI command, and it does not block TRIM on that, so hdparm works.

The only one I've seen that supports UNMAP->TRIM is JMicron JMS567.

However, the implementation seems to be only partially done. Apparently it does not support / has issue with queued UNMAP commands though (assuming the uas driver in the kernel is doing everything right). Therefore, blkdiscard/fstrim will work fine with the usb-storage driver (`u` quirk), but will have issue with the uas driver on it.

Also, for some reason (maybe the aforementioned one), it has the LBPME bit set to 0. So you need to change the provisioning_mode sysfs file with `echo -n unmap` too (though that can be necessary anyway when the usb-storage driver (u quirk) is in use, since it prefers Read Capacity (10), which does not check the LBPME bit at all).

Unlike the ASMedia chips, it seems to block TRIM in its ATA PASSTHROUGH btw.

similar or same bug reported at upstream
https://bugzilla.kernel.org/show_bug.cgi?id=83181

On the Orico M.2 NVME SSD enclosure which claims to support UASP, trim did not work on a fresh Ubuntu 24.04 install until a rule was added to /etc/udev/rules.d. The lsblk --discard sda output also listed a DISK-MAX of 0 for all partitions. After the rule (below) added (with proper vendor and product ids from lsusb), the DISK-MAX was 4G and fstrim succeeded. See Allen's 2020 answer on https://askubuntu.com/questions/262154/trim-and-ssd-with-usb-3-0-enclosure-does-not-work-uasp-not-supported

ACTION=="add|change", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="9210", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

I finally upgrade my 24.04 to 24.10, and now fstrim fails. I have the udev rules for all my USB SSDs, one old SATA two newer MVMe:

# cat /etc/udev/rules.d/10-uas-discard.rules
# Enable TRIM support for USB SSD enclosures.
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="235c", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="1351", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="2362", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Here are the kernel messages from attaching the SATA SSD:

[Mi Jan 1 18:37:14 2025] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[Mi Jan 1 18:37:14 2025] sd 2:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[Mi Jan 1 18:37:14 2025] usb 2-2: USB disconnect, device number 11
[Mi Jan 1 18:42:48 2025] usb 2-2: new SuperSpeed USB device number 12 using xhci_hcd
[Mi Jan 1 18:42:48 2025] usb 2-2: New USB device found, idVendor=174c, idProduct=1351, bcdDevice= 1.00
[Mi Jan 1 18:42:48 2025] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[Mi Jan 1 18:42:48 2025] usb 2-2: Product: RAPID-CASE U 3.1
[Mi Jan 1 18:42:48 2025] usb 2-2: Manufacturer: Sharkoon
[Mi Jan 1 18:42:48 2025] usb 2-2: SerialNumber: 2016050500000000000A
[Mi Jan 1 18:42:48 2025] scsi host2: uas
[Mi Jan 1 18:42:53 2025] scsi 2:0:0:0: Direct-Access CT1000MX 500SSD1 0 PQ: 0 ANSI: 6
[Mi Jan 1 18:42:53 2025] sd 2:0:0:0: Attached scsi generic sg2 type 0
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] 4096-byte physical blocks
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Write Protect is off
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Preferred minimum I/O size 4096 bytes
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[Mi Jan 1 18:42:57 2025] sdc: sdc1
[Mi Jan 1 18:42:57 2025] sd 2:0:0:0: [sdc] Attached SCSI disk

lsusb output:
Bus 002 Device 012: ID 174c:1351 ASMedia Technology Inc. RAPID-CASE U 3.1

systemctl status udev.service prints this:

Jan 01 18:42:48 alanya mtp-probe[396856]: checking bus 2, device 12: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb2/2-2"
Jan 01 18:42:48 alanya mtp-probe[396856]: bus: 2, device: 12 was not an MTP device
Jan 01 18:42:48 alanya mtp-probe[396862]: checking bus 2, device 12: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb2/2-2"
Jan 01 18:42:48 alanya mtp-probe[396862]: bus: 2, device: 12 was not an MTP device
Jan 01 18:42:57 alanya (udev-worker)[396874]: sdc: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sdc' failed with exit code 1.
Jan 01 18:42:57 alanya (udev-worker)[396872]: sdc1: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sdc1' failed wi...