Enable TRIM / UNMAP on the Storage Expansion Card

If you’re using a Storage Expansion Card (SEC) like I do to house your root file system, you may want to enable TRIM / UNMAP on it. It seems like Linux is currently unaware that this device supports TRIM / UNMAP and it doesn’t enable it by default. Not to worry, all you need to do in order to enable it is to add a udev rule:

echo 'ACTION=="add|change", ATTRS{idVendor}=="13fe", ATTRS{idProduct}=="6500", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' | sudo tee /etc/udev/rules.d/10-framework-sec-trim.rules

Restart your Framework for the change to take effect.

This rule works for the 1TB SEC. If you have another model check the vendor and product IDs using lsusb and replace them in the command if they differ.

PS: LVMRAID mirror between an NVMe drive and the SEC works just fine :grin:

8 Likes

And what benefits does this bring?

Was gonna type something up but it turns out Crucial explains it well enough here. In a single sentence - if you want your SSD to keep writing quickly over time and last long, especially when the data is encrypted before it’s written (the controller can’t tell a used from unused piece of data), you want to have TRIM working.

4 Likes

Tangentially related, but do you know if UNMAP is exposed through the microSD expansion card? In my experience, built-in SD readers do expose it, but USB readers don’t.

1 Like

Unfortunately I don’t know. Don’t have the reader.

1 Like

As the expansion cards are connected via USB C, you are going to be using a USB based reader. I don’t think this is definitive on whether it supports UNMAP, but just for your information.

1 Like

@lightrush By the way, this is valid for almost every USB SSD that you attach under Linux. Don’t know why, but by default there is no TRIM enabled for external SSDs under Linux.

While doing the research on this, I found some reports claiming that doing TRIM on some devices that don’t support it ended up erasing part of their firmware. I don’t know how veritable that is but if at all possible, then we probably have to enable it on case-by-case basis. Unfortunately. :expressionless:

1 Like

Is it possible to use the command(change the framework to other names) work on any other external known SSDs(not flash memory USB thumb drive)?

Read the post right above yours. It may not be safe on all drives.

I have an SSD reused from an older laptop as a portable drive (Samsung 870 QVO) and it trimmed successfully. How I can only trim this on Windows and if the drive is formatted as NTFS, I can’t trim on Linux even if I format this drive as ext4

This is due to the drive not being compliant with the SCSI command standard(which the USB Mass Storage devices are based on), usually, such devices don’t advertise the LBPME(logical block provisioning management enable) bit to the host which is a prerequisite to enable the SCSI UNMAP command on Linux systems.

Refer sd: disable logical block provisioning if ‘lbpme’ is not set - Patchwork for the background reasoning why this is implemented that way.

The patch you refer to was never merged and it is related to SD cards, not our SSD Expansion Card.

The Framework SSD Expansion Card does support unmap and is enabled automatically by the windows driver.
It’s also possible to force-enable on Linux, as mentioned in this thread.
Gentoo and Arch Wiki have that documented, as well.
https://wiki.gentoo.org/wiki/Discard_over_USB
https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support

The bits in the SSD Expansion Card firmware are set to confirm that unmap is indeed supported. Only the bit to automatically enable it in Linux is missing. We have limited control over the firmware of the controller, since it’s a standard part of a sub-sub supplier. We are always trying to push suppliers for Linux support but by default they always just care about Windows :confused:

4 Likes

Already messaged you privately about it but I figured it might as well be posted here to benefit everyone:

You’re right, however, the behavior seems to be the same in the kernel code:

The kernel won’t bother to detect UNMAP-related features when the LBPME bit of the SCSI READ CAPACITY response isn’t set.

That’s unfortunate but expected. I still appreciate your effort, though.
Hopefully, this can be fixed in a future batch of the product so we don’t need that workaround.