Enabling trim on external ssd on raspberry-pi

ARM
1

After updating the firmware (startech) I can enable trim. But should I modify “discard_max_bytes” according to this blog https://www.jeffgeerling.com.
I have the exact same value that this guy.
Logical block length=512 bytes
Maximum unmap LBA count: 4194240

echo 2147450880 > /sys/block/sda/queue/discard_max_bytes

Right now I have just followed the wiki.archlinux and the discard_max_bytes went automatically from 0 to 4294966784 after

sudo fstrim -v /

arch wiki 4294966784 vs jeffgeerling 2147450880 ?

2

You might find this of interest.

I too setup my SSD for trim and it appeared to be functional, but ultimately the trim.timer would error. So I wait.

3

I have read a little before kernel 5.18.
The kernel’s doc says

(RW)
While discard_max_hw_bytes is the hardware limit for the device, this
setting is the software limit. Some devices exhibit large latencies when
large discards are issued, setting this value lower will make Linux issue
smaller discards and potentially help reduce latencies induced by large
discard operations.

and the jeffgeerling’s blog made a rule without a forced discard_max_hw_bytes after a reboot.

The comments and https://lemariva.com/ say to use a persistence of discard_max_bytes only if that after rebooting the system throws I/O errors, and it disables TRIM.

I will test with the simple rule without a forced discard_max_hw_bytes

cat /sys/block/sda/../../../../../../idVendor
174c
cat /sys/block/sda/../../../../../../idProduct
55aa
sudo nano /etc/udev/rules.d/10-trim.rules

ACTION==“add|change”, ATTRS{idVendor}==“174c”, ATTRS{idProduct}==“55aa”, SUBSYSTEM==“scsi_disk”, ATTR{provisioning_mode}=“unmap”

4

reboot is ok

cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
unmap

cat /sys/block/sda/queue/discard_max_bytes
4294966784

Should I enable fstrim.service (inactive) and fstrim.timer (active) ? The wiki talks just about the timer.

$ systemctl status fstrim.service
○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
    Active: inactive (dead)
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)
$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
     Active: active (waiting) since Fri 2022-01-21 19:52:53 CET; 4min 56s ago
      Until: Fri 2022-01-21 19:52:53 CET; 4min 56s ago
    Trigger: Mon 2022-01-24 01:37:54 CET; 2 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

janv. 21 19:52:53 manjaro systemd[1]: Started Discard unused blocks once a week.
5

Just the fstrim.timer, the .timer activates the .service at the scheduled time.

6

It seems successful :

systemctl status fstrim.service
○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead) since Mon 2022-01-24 07:14:30 CET; 5h 1min ago
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)
    Process: 10103 ExecStart=/usr/bin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported (code=exited, status=0/SUCCESS)
   Main PID: 10103 (code=exited, status=0/SUCCESS)
        CPU: 2.806s

janv. 24 07:13:48 manjaro systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
janv. 24 07:14:30 manjaro fstrim[10103]: / : 161,8 GiB (173719052288 octets) réduits sur /dev/sda2
janv. 24 07:14:30 manjaro fstrim[10103]: /boot : 158,4 MiB (166080512 octets) réduits sur /dev/sda1
janv. 24 07:14:30 manjaro systemd[1]: fstrim.service: Deactivated successfully.
janv. 24 07:14:30 manjaro systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
janv. 24 07:14:30 manjaro systemd[1]: fstrim.service: Consumed 2.806s CPU time.
1 Like