TRIM on an external SSD for the RPi

TRIM offers better performance when we use a SSD because it knows which areas contain data that is no longer in use. It has been recently discovered how to activate it on RPi (https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi).

Is it possible to activate TRIM in on HASS OS for RPi?

I’d like to throw my hat into supporting this feature also. I’m running HassOS in a virtual environment (Linux / KVM) and I’ve found that the HassOS Guest image (qcow2) will easily grow beyond the actual storage being used. Similar to how TRIM will notify the SSD hardware of all the free blocks so it can start using them, TRIM will notify the virtual storage engine to allow it to free up all unused space in the guest image.

The HassOS image does provide the command line tool to manually trigger TRIM (fstrim -av) but there isn’t a way to have this command run on a schedule (cron, systemd, etc…) that I’ve been able to find mainly due to most of HassOS being read-only.

As an example, I just manually ran fstrim -av and it freed up over 8GB of space and it has only been a few days since I ran it previously.

HassOS supports systemd so having a fstrim service, which can be disabled by default, added that runs “fstrim -a” daily / weekly would be nice to have for people that want to enable it.

1 Like

Yes, it’s absolutely possible! I’ve studied the matter and activated it myself, so I wrote a step by step guide on my blog website. Unfortunately it’s written in Italian language but I believe that with google translator it could be easily understood.
Here the address of the guide: https://henriksozzi.it/2021/01/ssd-con-trim-raspberry-pi4-procedura-ufficiale/
If that will be useful I can translate it to english…
Just some notes:

  • TRIM is also very useful for a long live of the SSD as will ensure wear leveling, so that every write will be in different flash cell and the wear will be distributed, not concentrated on the same cells. That the main reason that pushed me to activate it.
  • There isn’t a good way to ensure that your controller and SSD supports TRIM, if that’s not stated by the producer or you find that other people already tested that (as per Jeff Geerling article). So activate it at your own risk. Personally I’m using a Geekwork X857 mSata controller v1.2 with a 120GB Transcend SSD and it’s working flawlessy from nearly three weeks.
1 Like

Thanks a lot (or grazie !!!) it worked for me.
Google translate was good enough to activate TRIM it on my SSD

1 Like

You’re welcome (prego)! I’m happy it was useful to you! I was also struggling to activate it :slight_smile:

Hello - I have HA loaded on a KVM within Proxmox provisioned on lvl-local then pool on and SSD. I’d like to enable trim to be automatically ran as this drive keeps filing up. Thanks for writing these instructions. However, when I try to issue a lsblk command within the terminal I getL
zsh: command not found: lsblk

Any idea why?

Well, nearly one year passed (sorry, didn’t had any notification…) but the reply is: because you’re doing that through the SSH addon. You have to do it through the ssh dev port (22222, linked in the article the guide to open that port) or through the console.

Add a shell_command for example like this:
fstrim: "fstrim -v /config > /config/fstrimlog.txt"

And simply make an automation to call the service once a day, for example:

- id: fstrim
  alias: 'fstrim'
  initial_state: 'on'
  trigger:
    - platform: time
      at: '01:30:00'
  action:
    - service: shell_command.fstrim

You’ll get a fstrimlog.txt in your config folder showing the number bytes trimmed off.

1 Like

Home Assistant OS already has the fstrim.timer service running which automatically runs fstrim against all mounts which support it on a weekly basis.

You can see this if you connect to the console (monitor & keyboard) and type “login” at the ha supervisor prompt to get a shell. You can then do “systemctl status fstrim.timer” to see it’s status (you should see that it’s active and waiting). The fstrim.timer runs every week by default and when it runs it basically just does “systemctl start fstrim.service” which performs the fstrim on the filesystems then stops itself.

You can look in the files /usr/lib/systemd/system/fstrim.timer and /usr/lib/systemd/system/fstrim.service to see their respective configs. I don’t recommend increasing the fstrim beyond the default of weekly if you’re running Home Assistant OS on an SD card or on an SSD as it’s harder on the SSD to do it more frequently and will affect it’s lifespan.

To recap, there’s no need to schedule an fstrim in Home Assistant if you’re running Home Assistant OS because it’s already automatically handled (weekly) at the OS level.

Hope that this info helps some folks who come across this thread.

Just to add, unfortunately there doesn’t seem to be an easy way to change this to a daily schedule if you need to since the root filesystem on home assistant OS is read-only. I haven’t been able to find any guides anywhere to do this so we’re essentially stuck with the weekly schedule unless someone can find a way to modify the config.

2 Likes

I have DATA SET MANAGEMENT errors due to TRIM:

While it cannot be disabled completely due to the read-only system filesystem, I have found that

systemctl stop fstrim.timer

should disable trim for the current session.

does anybody have an idea how to change the hassio image so that fstrim is not called in the first place? Or how to disable the service automatically on bootup? it’s really annoying that when I forget to call it manually, the database gets corrupted the next weekend…