Arch Linux

Elmario

Member

Registered: 2023-08-21

Posts: 75

Cannot get TrIm working on external NVME-SSDs-

Hello!
I am on current arch using Zen kernel from the official Arch repos (Linux work 6.16.10-zen1-1-zen). Udev is the default systemd-udevd.

I am trying to enable TRIM on my external NVME-USB-enclosures which I have several of.
fstrim just claims 'the discard operation is not supported' which is wrong for all enclosures.

The usual way for force enabling Trim usually seems to be by udev in this case.

This is my udev configuration:

$cat /etc/udev/rules.d/10-uas-discard.rules
#Realtek RTL9210 enclosures
ACTION=="add|change", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="9210", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

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

#Sharge Disk
ACTION=="add|change", ATTRS{idVendor}=="2d01", ATTRS{idProduct}=="d709", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

I have a ton of chatter from udev in debug-log mode. But please tell me how I to find the relevant section to post, or what to look for in the log, so you can help me, because I don't want to spam the thread and post a huge bunch of text which might contain personal data somewhere from journalct.
The only possibly relevant thing I found myself, yet is:

Okt 20 12:28:29 work (udev-worker)[344489]: 1:0:0:0: /etc/udev/rules.d/10-uas-discard.rules:8 ATTR{provisioning_mode}="unmap": Writing "unmap" to sysfs attribute "provisioning_mode".
Okt 20 12:28:29 work kernel: sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Okt 20 12:28:29 work (udev-worker)[344486]: sd-device: Failed to chase symlinks in "/sys/bus/dmi/devices/id".
Okt 20 12:28:29 work (udev-worker)[344486]: sd-device: Failed to chase symlinks in "/sys/firmware/dmi/id".

I don't know if this is normal .. these paths don't even exist in /sys

Thank you!

Last edited by Elmario (Yesterday 11:18:48)

unixman

Member

Registered: 2015-03-12

Posts: 141

Re: Cannot get TrIm working on external NVME-SSDs-

first:

`find /sys/devices -type f -name trim`

then:

cat `find /sys/devices -type f -name trim`

if all OK then read/search kernel_SRCROOT/Documentation/admin-guide/kernel-parameters.txt for trim.
there is "trim" under libata.force  for kernel cmdline.
this may be different approach than you looking for btw.

Last edited by unixman (Yesterday 11:44:28)

topcat01

Member

Registered: 2019-09-17

Posts: 244

Re: Cannot get TrIm working on external NVME-SSDs-

Please also post

lsblk -D

Elmario

Member

Registered: 2023-08-21

Posts: 75

Re: Cannot get TrIm working on external NVME-SSDs-

Hello thank you two!

I ran the commands with one SSD of each model type (As seen in the udev rules files in first post) connected to the PC.
Here are the results:

`find /sys/devices -type f -name trim`

This finishes wit no output. Is this possibly because the symlinks where not created by udev?

cat `find /sys/devices -type f -name trim`

This does not finish. It keeps running for eternally with no output. I have to press CTRL-C for stopping after (probably because there was nothing found by 'find').

lsblk -D
[sudo] Passwort für ladmin: 
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        4K       4G         0
├─sda1             0        4K       4G         0
├─sda2             0        4K       4G         0
├─sda3             0        4K       4G         0
├─sda4             0        4K       4G         0
└─sda5             0        4K       4G         0
sdb                0      512B       4G         0
├─sdb1             0      512B       4G         0
├─sdb2             0      512B       4G         0
├─sdb3             0      512B       4G         0
├─sdb4             0      512B       4G         0
└─sdb5             0      512B       4G         0
sdc                0        0B       0B         0
sdd                0        0B       0B         0
sde                0      512B       4G         0
├─sde1             0      512B       4G         0
└─sde2             0      512B       4G         0
zram0              0        4K       2T         0
nvme0n1            0      512B       2T         0
├─nvme0n1p1        0      512B       2T         0
├─nvme0n1p2        0      512B       2T         0
├─nvme0n1p3        0      512B       2T         0
├─nvme0n1p4        0      512B       2T         0
├─nvme0n1p5        0      512B       2T         0
├─nvme0n1p6        0      512B       2T         0
├─nvme0n1p7        0      512B       2T         0
├─nvme0n1p8        0      512B       2T         0
└─nvme0n1p9        0      512B       2T         0

The external SSDs are sda, sdb and sde. sdc and sdd are just sd card readers.

Here one can see volumes on all SSDs being recognized and having been optimized from a Windows system, just for ensuring my self I am not fantasizing that it's possible xD

Last edited by Elmario (Today 04:35:42)

unixman

Member

Registered: 2015-03-12

Posts: 141

Re: Cannot get TrIm working on external NVME-SSDs-

Ahh.

$ find -H /sys -type f -name trim
$ cat `find -H /sys -type f -name trim`

$ find -H /sys -type f -name provisioning_mode
$ cat `find -H /sys -type f -name provisioning_mode`

$ echo unmap > `find -H /sys -type f -name provisioning_mode`

that last is write ALL  'provisioning_mode's it found.

So it left you as exercise to fix it if needed:)

BTW: https://www.kernel.org/doc/html/latest/ … eters.html

Last edited by unixman (Today 06:32:23)

Elmario

Member

Registered: 2023-08-21

Posts: 75

Re: Cannot get TrIm working on external NVME-SSDs-

OK!

The first two commands act the same as before (no output),

The other commands:

# find -H /sys -type f -name provisioning_mode
/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb10/10-1/10-1.2/10-1.2:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/provisioning_mode
/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb10/10-1/10-1.1/10-1.1:1.0/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0/provisioning_mode
/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb9/9-1/9-1.4/9-1.4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode
/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.1/4-1.1:1.0/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1/provisioning_mode
/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.1/4-1.1:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0/provisioning_mode

# cat `find -H /sys -type f -name provisioning_mode`
full
unmap
unmap
full
full

# LANG=en_US.UTF-8 echo unmap > `find -H /sys -type f -name provisioning_mode`
bash: `find -H /sys -type f -name provisioning_mode`: ambiguous redirect

Also I tried to find what disk is behind which path, by blindly trying through until I got something, as I don't understand how to use 'find' in any efficient manner. At least I found them all three:

# cat "/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb9/9-1/9-1.4/9-1.4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/device/vendor" 
Sabrent 

# cat "/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb10/10-1/10-1.1/10-1.1:1.0/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0/device/vendor" 
JMicron 

# cat "/sys/devices/pci0000:00/0000:00:08.3/0000:08:00.4/usb10/10-1/10-1.2/10-1.2:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/device/vendor" 
SHARGE  

What irritated me, that while trying to find how I could get which disk is behind which device path, I also issued an 'lsub -t' and got this result:

lsusb -t | grep uas
        |__ Port 001: Dev 003, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 002: Dev 004, If 0, Class=Mass Storage, Driver=uas, 10000M

So there's only two drives loaded with uas driver, while there are three connected .. but anyway trim is not working for any of them.

Overall:
I don't understand what 'ambiguous redirect' is supposed to tell me, as what I found online about it seems .. rather ambiguous ...  (it seems to mean something like a link to a non valid target, but the target is not actually wrong, it's just the link won't work under certain circumstances, or what?).
But I think the provisioning_mode search says they should all work.- doesn't it? Overall I think it might come down to the linking not working as seen in the log .. but there's no clue to why it won't work.

EDIT:
OK, one more pehnomenon added to the confusion:
I just noticed that the Sabrent (RTL9210) disk finally IS working for fstrim (and I don't know why, maybe because I restarted the system since, despite this should not make a differences, as I was restating the udev service, reload it's config amd and monitor manually before, already ..)!
It's still not working for the other models of enclosures .. ('the discard operation is not supported')

Last edited by Elmario (Today 15:48:39)