The Raspberry Pi Trim Function Revisited

Tagged with linux, raspberry pi, trim on May 7, 2024

When I initially wrote about my Raspberry Pi 400 (“Pi” for short), I included the steps I took to enable the trim function on an SSD connected by USB. At the time, those steps were correct. I got that information from an article by Jeff Geerling, which he wrote in 2020.

Note: I edited this two weeks later, just to remove some inaccuracies.

Resetting Trim

When I initially tested things, the command “lsblk -D”, would show zeros under “DISC-MAX” and the “sudo fstrim -v /” command would tell me “fstrim: /: the discard operation is not supported”. Once I followed all the steps to enable it, it would show “4G” under “DISC-MAX” and the command would perform the trim function. It would then be disabled until the next boot.

The provisioning mode starts out as “full”. “Unmap” is the provisioning mode required for fstrim to operate. Jeff Geerling’s code works and changes it to “unmap” when booting. After the trim function completes, the provisioning mode will become “disabled”, and if you suspend or hibernate the computer for weeks at a time, it will remain “disabled”. The same thing will happen if you simply leave it on for months at a time.

That’s the way I’m using mine (always on), and I don’t want to reboot just to get the trim function working again. So, I created a solution.

My BASH Script

This is the script:

#!/bin/bash
if [ "cat /sys/block/sda/device/scsi_disk/*/provisioning_mode" != "unmap" ] ; then
    echo unmap | tee /sys/block/sda/device/scsi_disk/*/provisioning_mode
fi

The script reads the provisioning mode and if it isn’t “unmap”, it changes it to “unmap”. Short and sweet. It has to be run as root, so I have it set up as an hourly cronjob with “sudo crontab -e”. It doesn’t actually do anything until after the weekly fstrim function is invoked by the systemd timer and the provisioning mode is changed to “disabled”.

Image by Raspberry Pi