fstrim no longer working on some external USB enclosures

[Gordon Lack]

Having upgraded from Jammy to Kinetic I now find that fstrim no longer works on SSD drives in some external USB enclosures.

The issue is caused by the provisioning_mode status for these now being set to disabled, whereas previously they were set to unmap.

Oddly(?) this only occurs on hot-plugging. I have two of these "permanently" plugged in to one system (so there at boot time) and these still show up as unmap.
But if I plug in a third enclosure (same chipset, same SSD model, same SSD firmware version as the second one) it shows up as disabled.

==========
root@benuc:~# lsusb
Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s
Bus 002 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@benuc:~# cd /sys/
/sys
root@benuc:/sys# find -name provisioning_mode
./devices/pci0000:00/0000:00:17.0/ata2/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode
./devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0/provisioning_mode
./devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/provisioning_mode
./devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/host4/target4:0:0/4:0:0:0/scsi_disk/4:0:0:0/provisioning_mode
./devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0/provisioning_mode
root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/provisioning_mode
unmap
root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/host4/target4:0:0/4:0:0:0/scsi_disk/4:0:0:0/provisioning_mode
unmap
root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0/provisioning_mode
disabled

==========

(Ignore the ata entries - those are internal drives).

If I reboot the system using the old, kept Jammy kernel (5.15.0-52-generic) the hot-plug shows up as unmap again.

It's the 5.19.0-2?-generic Kinetic kernels which seem to be causing the problem.

I do have a workaround of providing my own udev rule:

ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0578", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

which is something I've had to do anyway for some other ASMedia chipsets which do work, but don't get set to unmap by default - 174c:55aa and 174c:235c.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stanislav Sidorenko (ssidorenko)]

Stopped working for holplug after update to 22.10

Bus 002 Device 016: ID 152d:0580 JMicron Technology Corp. / JMicron USA Technology Corp.

provisioning_mode file has 'disabled' value even with the following udev rule:

ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0580", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Interesting that it works fine on first plug (provisioning_mode=unmap), but does not work on second and next plugs - provisioning_mode is always disabled.

[Stanislav Sidorenko (ssidorenko)]

And one update. Having udev rule defined it is possible to fix provisioning mode by executing this command:

udevadm trigger --verbose --subsystem-match=scsi_disk

[Steve Dodd (anarchetic)]

Not sure this is reported against the right package, BTW :)

I've used a hacky script started from udev to verify that the change is happening OK, and to start an inotify on /sys - it doesn't appear that whatever is resetting provisioning_mode is doing so that way, so it must be happening at a lower level :(

[Steve Dodd (anarchetic)]

FWIW, I am using Jammy, but with an HWE kernel, which points the finger at the kernel rather than userspace.

[Gordon Lack (gordon-lack)]

My original post said it was a kernel issue, so no idea why it was logged against konsole.

I've changed it.