I’ve created the following udev rule: ~]$ cat /etc/udev/rules.d/15-uas-discard.rules ACTION=="add|change", ATTRS{idVendor}==“174c”, ATTRS{idProduct}==“55aa”, SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
fstrim refuses to trim the drive, saying the discard operation is not supported, even after adding the udev rule and rebooting.
tl;dr is there some alternative way to TRIM without using “discard?” Or am I doing something else wrong here?
Drive data:
~]$ lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E
[victorsuede@Nicole ~]$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
TRIM is clearly supported by the hardware:
~]$ sudo smartctl -a /dev/sda
smartctl 7.2 2020-12-30 r5155 [aarch64-linux-5.10.17-2-MANJARO-ARM] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: Lexar 512GB SSD
Serial Number: LDG908W101142
LU WWN Device Id: 5 3a5a27 00000095a
Firmware Version: SN07373
User Capacity: 512,110,190,592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun Nov 21 20:34:37 2021 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Not really, since it’s connected over USB, that might be the problem source. A USB bridge controller that supports SCSI/ATA Translation Pass Through is required, but none exists. Trim command cannot be sent over USB.
It’s almost like trying to use the Pi as a general purpose computer/mini-server, instead of the maker board it was designed to be, is a bad idea. (Seriously, so many of my issues would be solved by having bought a Compute Module 4.
I used to use an ORICO USB NVME adapter to use an NVME SSD in my Pi. TRIM seemed to work on that.
So, how much faster am I killing my drives without TRIM enabled?
Hard to guess, basically the good ol’ rule stands: if you keep writing on to the same cells, it would wear out faster. TRIM would help this since it helps erasing actually unused cells, writes can go to those cells instead of overwriting existing ones.
Several USB-to-SATA bridge chips (like VL715, VL716 etc.) and also USB-to-PCIe bridge chips (like the JMicron JMS583 used in external NVMe enclosures like IB-1817M-C31) support TRIM-like commands that can be sent through the USB Attached SCSI driver (named “uas” under Linux).
But the kernel may not automatically detect this capability, and therefore might not use it. Assuming your block device in question is /dev/sdX, you can find out whether that is the case by using the command
# sg_readcap -l /dev/sdX
If in its output you find a line stating “Logical block provisioning: lbpme=0” then you know that the kernel assumes the device does not support “Logical Block Provisioning Management” because the (LBPME) bit is not set.
It goes on to describe further diagnostics. I’m going to play with this and see if I can get anything useful out of it.
You’ll need the sg3_utils package from the repos to use the commands it lists.
Test results from another Pi, where I’m booted off a Samsung T5 external SSD, that also supports TRIM according to the testing steps from the ArchWiki…
I followed the directions in that wiki article, and manually echo’d the unmap command into the appropriate part of the /sys/block/sda/ tree.
I had to su root to do it. sudo was not enough.
But…
]# fstrim -v -a
/boot: 94.8 MiB (99388928 bytes) trimmed on /dev/sda1
/: 429.4 GiB (461097222144 bytes) trimmed on /dev/sda2
The article implies the udev rule should do exactly the same thing, just as I’ve written it, but it doesn’t.
So … yay, manual TRIM is doable (at least on a SAMSUNG T5, which connects directly to the Pi and is recognized correctly by lsusb), but the udev rule failing remains a mystery.
On reboot, the Pi with the Samsung T5 is back to this:
❯ sudo fstrim -v /
fstrim: /: the discard operation is not supported
I’ll test the other Pi, which uses a USB bridge to a SATA SSD, tomorrow. In the worst case, I can just make a note in my calendar to manually trim any disks that will let me do it once a week.
EDIT: I successfully TRIM’d the Lexar SSD using this method.
I think it should. I’ve not done it before, but I know there’s lots of tutorials on using cron.
I’m a bit concerned that the udev rule doesn’t work. I don’t know if that’s an issue with my hardware, or something wrong with whatever is supposed to make the udev rules work. Is there a way I can test to make sure the custom rules are actually being applied at all? (e.g., with some test rule that does something unrelated to any of this, with a known correct result?)
(Seriously, so many of my issues would be solved by having bought a Compute Module 4.