fstrim not running on external USB SSD. Secondary issue - not running frequently enough

[TheOriginalMrWolf]

Describe the issue you are experiencing

Hi.

Running

Home Assistant 2023.8.3
Supervisor 2023.08.1
Operating System 10.5
Frontend 20230802.1 - latest

...on Raspberry Pi 4 Model B 8 GB, booting from externally attached USB3 Samsung T7 SSD drive.

Looks like by default the OS is not running fstrim on this (or a large number of other) drives. This is bad as it will seriously impact performance and lifecycle through write amplification.

The (no doubt temporary) fix in my case was to identify vendor & product IDs (no thanks to the installed version of lsusb that doesn't like acting on -t flag), and create a udev rule:

/etc/udev/rules.d/55-usb-ssd-trim.rules

ACTION=="add|change", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="4001", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

After reboot fstrim now happily works on this drive.

I'm confident running fstrim on this particular drive won't cause an issue as I've been doing so with Samsung T5 & T7 on Raspberry Pi and Odroid N2 for several years now without problem. These drives are in fact quite fabulous to use with Raspberry etc - bullet proof, reliable, highly performant (as long as UASP is enabled... next issue...), and (relatively) cheap.

It would be great if we could either have a way for users to enable fstrim for their particular drives, or perhaps have a list of 'pre-qualified' / 'recommended' drives with prebuilt matching udev rules.

Secondary issue: fstrim isn't running frequently enough. Once per week, especially on smaller drives, isn't very good in my opinion.

I would have liked to have created an override to run this daily, unfortunately the filesystem is RO and so systemctl edit fstrim.service can't run.

It would be great if this could be set to run daily by default (or maybe allow users to configure?).

Thanks!

What operating system image do you use?

rpi4-64 (Raspberry Pi 4/400 64-bit OS)

What version of Home Assistant Operating System is installed?

10.5

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

Boot HASS OS from external USB SSD on RPi4.

Log into base OS via SSH, run fstrim -a --verbose & inspect the result.

Anything in the Supervisor logs that might be useful for us?

No.

Anything in the Host logs that might be useful for us?

No.

System information

No response

Additional information

No response

[agners]

Hm, not sure how to handle this, there are so many USB SSD's out there... Do other distribution have udev rules for known PID/VID? Is there maybe a known good list somewhere? :thinking:

[TheOriginalMrWolf]

This article talks about a way to query the drive's capabilities and configure TRIM on the fly. Should be pretty easy to include the required tools & script as part of the startup process? That way you wouldn't need to create a monster udev rule file & could also pretty easily implement a per-drive switch on/off for the feature in case people run into issues.

What do you think @agners - configurable switch in system configuration to enable/disable?

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[TheOriginalMrWolf]

Hi @agners - just wondering if you've been able to have a look at the above?

[agners]

I have not really delve into it, no.

While I've seen people manually enabling discard support on USB attached storage, I really wonder why this is necessary to manually setup? E.g. why does the kernel not do this by default? Typically there is a reason, e.g. some drives might misbehave. I remember a case where power S-ATA savings were disabled by default. Enabling it did work in most cases, but in some it lead to actual data loss. I had such a case, luckily only the first 1MB was usually cleared, which was able to recover. But anyhow, I rather take a conservative stance on enabling features which potentially lead to data loss. The past has shown that fstrim caused discard can lead to dataloss, although in a different setup back then.

I do see the appeal to add this feature, as it helps longevity if it works correctly. But it is currently not a priority on my end, I am sorry :cry:

With Raspberry Pi 5, native NVMe disk support finally came to the Raspberry Pi SBC world. I expect more and more mass storage being directly connected through NVMe, where fstrim/discard works by default.

That said, I am happy to review/accept PRs which implement fstrim USB suppport. Probably the Arch Linux Wiki and Gentoo Wiki are also good resources for implementing such a feature.

Btw, unfortunately quite some folks would probably not being able to make use of that feature as it requires UAS to work. E.g. issue #1743 suggested to disable UAS globally. We did not went that far, but unfortunately we had to disable it for quite some controllers using USB PID/VID because of buggy firmwares :cry:

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.