So what's the deal with SSD's and TRIM in Linux nowadays?

Coffee break
1

It’s been a while since I last tried to run my daily driver PC with Linux. I’ve tried various distros on hobby laptops over the years, but I usually gave up whenever I encountered issues with drivers or grub config or broken dependencies etc.
The last time I tried to do a serious build I was dual booting Linux Mint with Windows 7, I remember it was the first time I installed an SSD and I remember my colleague stressing it was important to setup this feature called Trim to ensure longevity of the SSD.
I don’t hear a lot said about Trim nowadays, and when I search for terms like “linux ssd trim”, I get the impression that nowadays this is an automatic process, according to a reddit post, "Every modern operating system, including Linux, automatically enables TRIM for solid-state drives, you don’t need to do anything by default.".
For what it’s worth I haven’t ever deviated from the default option to use ext4 format drives for Linux (I think the first time I installed Mandrake Linux it used ext2 or ext3).
So is the above quote true for a fresh install of OM Lx 6.0? I don’t have to manually enable anything post installation on an SSD using ext4?

2

Here you go:

https://wiki.archlinux.org/title/Solid_state_drive#TRIM

1 Like
3

I didn’t come across this page yet, so the resource is much appreciated.

From past experience, I prefer to delineate between a daily driver and a hobby setup, where there’s a clearer line between what can be done and what must be done to maintain a working main system. When I get home I will run some of those diagnostic queries to find out what services are currently in place by default.

4

OS: OpenMandriva Lx 6.0 (Vanadium) Rock x86_64

diagnostic queries:

[-----@Polvo ~]$ lsblk --discard
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
├─sda1        0      512B       2G         0
├─sda2        0      512B       2G         0
├─sda3        0      512B       2G         0
└─sda4        0      512B       2G         0
sr0           0      512B       0B         0
zram0         0        4K       2T         0
[-----@Polvo ~]$ sudo hdparm -I /dev/sda | grep TRIM
           *    Data Set Management TRIM supported (limit 8 blocks)

snip from /etc/fstab:

# <file system>      <mount point>  <type>  <options>  <dump>  <pass>
UUID=-----           /boot/efi      vfat    defaults,noatime 0 2
UUID=-----           /              ext4    defaults,noatime,discard 0 1
UUID=-----           /home          ext4    defaults,noatime,discard 0 2

From provided link above:

Using the discard option for a mount in /etc/fstab enables continuous TRIM in device operations

Is this sufficient confirmation I won’t need to do anything extra regarding TRIM?

5

Yeah, you’re good. Realistically, depending on your drive you don’t even need continuous. A big drive with lots of empty space it’s less important, and you could even go to 1/week or 1/month.

Especially if swap and temp are sitting in a ramdrive. OMLx sets up zram for either tmp or swap (I forget which). Since I have ram to spare I’m going to be setting up another zram drive for all my “temp stuff” - which takes all that away too.

You can do the same for the web browser cache - cache to ram rather than disk. The key is to have enough ram. If you have 16GB or more you should be ok given the OMLx default zram usage

The key to remember is that it’s the drive controller that handles most of the wrtiting and trimming. In the old days we would leave 15-20% of the drive empty for wear leveling - a habit I still practice actually which has come in surprisingly handy when I need to experiment with disk partitions or move things (and can’t find a usb…)

1 Like
6

Just wanted to make a quick update here:

If you’re going to create a ramdrive for temporary files, remember which temporary files you’re putting there.

Using tmpfs.mount to redirect /tmp is fine. /tmp is cleared with each reboot.

/var/tmp is intended for temp files that need to last between reboots

From the Linux Foundation:

3.18. /tmp : Temporary files
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

5.15. /var/tmp : Temporary files preserved between system reboots:
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html

For those who are curious about another “ramdrive” program Ramfs :
https://wiki.debian.org/ramfs

7

Hey I just wanted to say thanks for the clarification & extra info, I’ve been super busy so only just coming back to this now. At this point I only have 16GB in my main system so probably won’t be looking into this ramdrive stuff until I eventually get a new gaming pc, if I ever find the time.

8

YW. OpenMandriva already uses zram.

Use “df -h” in the terminal and look for “/dev/zram0” to see where it’s mounted (I’m not at an OM system atm). There’s also a bunch of posts here in the forum about it.

With 16GB of ram you’re fine for 90% of things.

If you primarily use firefox you can redirect all the temp stuff to ram from about:config and change the cache size at the same time. No need for a separate ramdrive.

Chrome is a pain in the rear. You are pretty much forced to use a ramdrive here. There are a couple command line flags you can try too.

If you use a lot of ram intensive programs you can try experimenting with zswap (replacing zram). Zswap acts as a cache for the swap file/partition. Zram is more flexible and can be tweaked to do the same as zwap. But I can’t say I’ve done any testing on it to see which is better in what scenario.

1 Like