SOLVED: Cannot get TRIM working on external NVME-SSDs-

Elmario · 2025-10-20 10:50:40

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 (2025-10-24 15:46:50)

unixman · 2025-10-20 11:37:27

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 (2025-10-20 11:44:28)

topcat01 · 2025-10-20 19:34:32

Please also post

lsblk -D

Elmario · 2025-10-21 04:20:41

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 (2025-10-21 04:35:42)

unixman · 2025-10-21 06:16:11

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 (2025-10-21 06:32:23)

Elmario · 2025-10-21 15:32:40

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 (2025-10-21 15:48:39)

topcat01 · 2025-10-21 17:46:41

I find the lsscsi command handy for identifying the disks in the find output.

I have never encountered a disk where lsblk -D shows DISC-MAX to be non-zero but fstrim does not work. I also have USB NVME enclosures (UGREEN). What is the filesystem on these?

Last edited by topcat01 (2025-10-21 17:50:04)

unixman · 2025-10-21 19:59:31

bash: `find -H /sys -type f -name provisioning_mode`: ambiguous redirect
my wrong; shell redirect cant accept multiple argument.

I just noticed that the Sabrent (RTL9210) ...
it is because that it is the first argument of above command.

#!/bin/sh

# choose the ones not already unmap
# grep -lv unmap `find -H /sys -type f -name provisioning_mode`

choose=$(grep -vl unmap `find -H /sys -type f -name provisioning_mode`)

for i in $ choose
do
    echo unmap > $i
done

Hook this to systemd to automate if you like.

Last edited by unixman (2025-10-21 20:18:46)

seth · 2025-10-21 21:59:31

my wrong; shell redirect cant accept multiple argument.

https://man.archlinux.org/man/tee.1 can

Edit: https://mywiki.wooledge.org/BashFAQ/082 - migrate your brain away from the backticks

Last edited by seth (2025-10-21 22:02:51)

Elmario · 2025-10-22 06:59:25

topcat01 wrote:

I find the lsscsi command handy for identifying the disks in the find output.
I have never encountered a disk where lsblk -D shows DISC-MAX to be non-zero but fstrim does not work. I also have USB NVME enclosures (UGREEN). What is the filesystem on these?

They are both shown as zero.
(sda and sdb currently, after some reboots and repartitioning due to countless retries of mine)

lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
└─sda1             0        0B       0B         0
sdb                0        0B       0B         0
└─sdb1             0        0B       0B         0
sdc                0        0B       0B         0
sdd                0        0B       0B         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

Currently they have just one ext4 partition each.

unixman wrote:

Hook this to systemd to automate if you like.

But why wouldn't it work with the usual udev entry (for the Realtek one)'? And why does it still not work for the other two controller models (I tried the new version/script)?

Last edited by Elmario (2025-10-22 07:04:23)

Elmario · 2025-10-22 07:02:07

------- sorry, double post

Last edited by Elmario (2025-10-22 07:02:46)

seth · 2025-10-22 07:24:11

I tried the new version/script

Did the provisioning_mode values change?
Have you tried flipping them manually?

But why wouldn't it work with the usual udev entry

I guess 1:0:0:0/device/vendor doesn't contain the literal vendor name, but are the VID/PID there the ones you're using in the udev rule or did you use the USB ones there?

unixman · 2025-10-22 08:45:26

v2:P
*remove backtits
*make more verbose

#!/bin/sh

found=$(find -H /sys -type f -name provisioning_mode)
echo $found

# choose the ones not already unmap
filtered=$(echo $found | grep -vl unmap)
echo $filtered

for i in $ filtered
do
    echo unmap > $i
    echo $i
done

Elmario wrote: But why wouldn't it work with the usual udev entry?

Either your rule has faults or for some reason rule never run. See below:

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".

Are you notice THE weirness? your rules single line cuts.
i bet that it is because your rule broken.

use udevadm info to DUMP your device's tree up to top most ancestor.
Then validate againist your rule.

plug then unplug then plug again then look at journal.

Last edited by unixman (2025-10-22 08:49:09)

Elmario · 2025-10-24 04:59:46

It's just so weird and confusing! It's hard to stay in plan, because of the arbitraryness:
After countless retries, some reboots in between, running the script often, fstrim currently also works for the JMicron controller case - and for whatever reaons is does so permanently, even without executing the script. Maybe I was too confused and only tried this device only with a non fstrim suitable filesystem before ..

So the current state overall is:
Directly from booting (with udev rules rules still in place):

The JMicron is sde (working from boot on before running the script)
The RTL9210 is sdc (not working before running the script)
The ShargeDisk is sdd (not working before running the script)

lsblk -D before running the script:

lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
sdb                0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
└─sdc2             0        0B       0B         0
sdd                0        0B       0B         0
└─sdd1             0        0B       0B         0
sde                0        4K       4G         0
└─sde1             0        4K       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

And after running the

script:

sudo ./test
/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.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 /sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.4/4-1.4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode
(Standardeingabe)
$
filtered

lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
sdb                0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
└─sdc2             0        0B       0B         0
sdd                0        0B       0B         0
└─sdd1             0        0B       0B         0
sde                0        4K       4G         0
└─sde1             0        4K       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

As far as my old and blind eyes don't fool me nothing changed.
Trim is only working for the JMicron.
I have got no idea why the RTL9210 was working at a point before and why the JMicron now is working like OOTB.
Also with the JMicron alone I noticed a weird behaviour: Everytime I insert it, there's a 50% chance for it to be shown as "JMicron Generic" in GSmartControl. It won't be possible to gather any SMART data from the drive inside in this case. The other 50% it takes between about 10 and 20 seconds, then the name will switch to the name of the SSD ('BC711 NVMe SK hynix 256GB') and SMART data can be read successfully. But maybe that's just an anomaly of the JMicron's firmware and not related to the other issue.

Last edited by Elmario (2025-10-24 06:33:14)

unixman · 2025-10-24 06:17:41

Please fix script again.

replace "$ filtered" with "$filtered" remove that space; cause to much haste to you sory.

Which ones are removable? Maybe systemd caches config and make it persistent for non-removables.

Last edited by unixman (2025-10-24 06:23:56)

Elmario · 2025-10-24 06:45:32

No problem there, I am happy you are enduring in trying to help me finding a solution

All three SSDs in question are external USB-NVME-enclosures. (sdc, scd and sde currently). The Micron one started working during these experiments, I assume it might be I had the wrong filesystem on there for fstrim even being able to trim. All drives for sure bear ext4 partitions now.
The only internal SSD nvme0n1. Trim has been working fine for the internal drive from the beginning.

Just for making the experiments a bit more streamlined:
When running the script, should I do so a) Before even connecting the SSDs? b) with the SSDs connected but not mounted or c) With the SSDs connected and mounted?
In which of these cases would I have to remove and reconnect the SSDs for the script to take place?

New try with the changed script:
lsblk -D before running:

lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
sdb                0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
└─sdc2             0        0B       0B         0
sdd                0        0B       0B         0
└─sdd1             0        0B       0B         0
sde                0        4K       4G         0
└─sde1             0        4K       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

lsblk -D after:

LANGUAGE=en_EN-UTF8 sudo ./test
/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.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 /sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.4/4-1.4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode
(standard input)
(standard
input)

LANGUAGE=en_EN-UTF8 lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
sdb                0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
└─sdc2             0        0B       0B         0
sdd                0        0B       0B         0
└─sdd1             0        0B       0B         0
sde                0        4K       4G         0
└─sde1             0        4K       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

sudo fstrim -v /media/RTL9210/ ; sudo fstrim -v /media/JMicron/ ; sudo fstrim -v /media/ShargeDisk/
fstrim: /media/RTL9210/: the discard operation is not supported
/media/JMicron/: 0 B (0 bytes) trimmed
fstrim: /media/ShargeDisk/: the discard operation is not supported

Edit:
I modified the script a bit now, trying o find why it doesn't work:

#!/bin/sh

found=$(find -H /sys -type f -name provisioning_mode)
printf 'Found: %s\n' $found

# choose the ones not already unmap
filtered=$(echo $found | grep -vl unmap)
printf 'Filtered: %s\n ' $filtered

for i in $filtered
do
        echo unmap > $i
        printf '%s Set to unmap! \n' $i
done

The (to me) more comprehensible result is:

sudo ./test
Found: /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
Found: /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
Found: /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
Found: /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
Found: /sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.4/4-1.4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode
Filtered: (standard
 Filtered: input)
 (standard Set to unmap! 
input) Set to unmap!

So there seems to be something wrong with what $filtered contains because of this echo+grep combination not yielding the desired result:

echo "/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" |  grep -vl unmap
(standard input)

It's same for all the device's pathes.

Last edited by Elmario (2025-10-24 07:57:10)

unixman · 2025-10-24 07:37:20

script assumed SSD's plugged or you have run script after plug.
OR modify that udev rule that run script automatically when it plugged.
Script must be run before them mounted. (not sure exacly, really )

Last edited by unixman (2025-10-24 07:38:48)

unixman · 2025-10-24 07:47:02

replace as such:

filtered=$(find -H /sys -type f -name provisioning_mod | grep -vl unmap)

Elmario · 2025-10-24 07:56:54

Edit2:
In the meanwhile I modified the script by simply skipping the filtering step and echoing 'unmap' to all pathes in $found. This actually does make TRIM work for all SSDs.
So this is proof of concept that it can also work on Linux for all the enclosures, nice.
But would the solution using a script be adequate for my daily use? I don't have these enclosures permanently connected, actually it's quite the opposite. I overall have four such cases an intend on buying more and I am using them like USB-thumb drives, not permanently connected to the PC. Thus I think now as we know that it's working by principle, making the udev rules function would be the next step.

seth · 2025-10-24 07:57:07

Fwwi, you don't need that script

seth wrote:

my wrong; shell redirect cant accept multiple argument.
https://man.archlinux.org/man/tee.1 can

As for the udev rules

seth wrote:

I guess 1:0:0:0/device/vendor doesn't contain the literal vendor name, but are the VID/PID there the ones you're using in the udev rule or did you use the USB ones there?

Elmario · 2025-10-24 08:06:16

Sorry, I forgot to reply on that:
Regarding udev:
I am using the VEN and DEV IDs from lsusb, yet-

cat /sys/devices/pci0000\:00/0000\:00\:08.1/0000\:07\:00.4/usb4/4-1/4-1.4/4-1.4\:1.0/host1/target1\:0\:0/1\:0\:0\:0/vendor
Sabrent

Do you mean this? Is there supposed to be another string than this one? So do by this you mean I could use another parameter in udev for identifiying the related controllers besides idVendor and idProduct?

EDIT:
Ah, thank you! right I now discovered 'udevadm info --attribute-walk --name='
Let's see if I'll be able to make something out of it!

For 'my wrong; shell redirect cant accept multiple argument.' I honestly did not understand what you meant with this. But now I think it's about the script, and that probably the last post of unixman fixes this.
But I now see the next step in making it work by udev.

unixman wrote:

replace as such:

filtered=$(find -H /sys -type f -name provisioning_mod | grep -vl unmap)

OK, this seems to work. Filtered: is outputting nothing anymore, which of course if because all drives are set to unmap already. Tthank you!

The right systemd-service type for this to add would be a oneshot, probably, right? (In case we can't get udev to work)

Last edited by Elmario (2025-10-24 08:13:20)

seth · 2025-10-24 08:32:40

Compare the vendor and (likely) product attributes to what's actually there.

unixman · 2025-10-24 08:43:24

Since you want freely plug, unplug in any time and expect it works;
AS LONG AS plug events triggers the service; then oneshot fits.

Otherwise it not fits; it must be backround service with some timer accompanied to not cause cpu LOAD.

as seth said script is HACK. you should try to tame udev.

Last edited by unixman (2025-10-24 08:45:31)

unixman · 2025-10-24 09:36:55

my last is still wrong. plaese take this.
i tested this WRT your case. confirm it is works.
off how long time to tame stupid script.
provided as oneliner. you will free to split if wants to adding verbose.

echo unmap | tee $(grep -vl unmap $(find -H /sys -type f -name provisioning_mod))

Elmario · 2025-10-24 13:39:54

unixman wrote:

my last is still wrong. plaese take this.
i tested this WRT your case. confirm it is works.
off how long time to tame stupid script.
provided as oneliner. you will free to split if wants to adding verbose.
echo unmap | tee $(grep -vl unmap $(find -H /sys -type f -name provisioning_mod))

Thank you very much!
A: Yes, it does work!

I have tried to identify what could be an adequate qualifier for adapting the udev rules instead of the USB-IDs.

sudo udevadm info --attribute-walk --name=/dev/sdb| grep vendor ; sudo udevadm info --attribute-walk --name=/dev/sdb| grep device ; sudo udevadm info --attribute-walk --name=/dev/sdb| grep product
    ATTRS{vendor}=="Generic "
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{vendor}=="0x1022"
    ATTRS{subsystem_vendor}=="0x1022"
    ATTRS{vendor}=="0x1022"
  looking at parent device '/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':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.1/4-1.1:1.0/host0':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.1/4-1.1:1.0':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1/4-1.1':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4/4-1':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb4':
  looking at parent device '/devices/pci0000:00/0000:00:08.1/0000:07:00.4':
    ATTRS{device}=="0x161e"
    ATTRS{subsystem_device}=="0x201f"
  looking at parent device '/devices/pci0000:00/0000:00:08.1':
    ATTRS{device}=="0x14b9"
    ATTRS{subsystem_device}=="0x14b9"

I already removed all the definitely irrelevant stuff.

So I guess I should be using 'vendor' or 'subsystem_vendor' instead of 'idVendor' or how exactly would I adapt these attribute names for udev?

Last edited by Elmario (2025-10-24 13:46:43)

Arch Linux

#1 2025-10-20 10:50:40

SOLVED: Cannot get TRIM working on external NVME-SSDs-

#2 2025-10-20 11:37:27

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#3 2025-10-20 19:34:32

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#4 2025-10-21 04:20:41

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#5 2025-10-21 06:16:11

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#6 2025-10-21 15:32:40

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#7 2025-10-21 17:46:41

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#8 2025-10-21 19:59:31

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#9 2025-10-21 21:59:31

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#10 2025-10-22 06:59:25

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#11 2025-10-22 07:02:07

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#12 2025-10-22 07:24:11

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#13 2025-10-22 08:45:26

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#14 2025-10-24 04:59:46

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#15 2025-10-24 06:17:41

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#16 2025-10-24 06:45:32

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#17 2025-10-24 07:37:20

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#18 2025-10-24 07:47:02

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#19 2025-10-24 07:56:54

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#20 2025-10-24 07:57:07

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#21 2025-10-24 08:06:16

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#22 2025-10-24 08:32:40

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#23 2025-10-24 08:43:24

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#24 2025-10-24 09:36:55

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

#25 2025-10-24 13:39:54

Re: SOLVED: Cannot get TRIM working on external NVME-SSDs-

Board footer