Enabling Synchronous TRIM Only

samsungssdtrim

I have a Samsung PRO Series SSD. Linux deactivates Trim for this SSD because it deletes the wrong data when asynchronous Trim is used (firmware bug).

Is it possible to activate synchronous Trim for it without activating asynchronous Trim, too?

My laptop in which I use this SSD only runs 1 operating system: Ubuntu 16.04. It's a LTS system so it only runs LTS kernels. The currently kernel is 4.4.0-57-generic.

Regarding firmware updates: A lot of users report that the firmware update failed for them. Furthermore, Samsung only offers its update software for Windows for the SSD I have. Its Linux version only supports certain business SSDs, the Windows version only certain consumer SSDs. Unfortunately, I don't have business SSD (and no Windows installation which I'm frankly rather glad about, most of the time). There seems to be a way to do the update anyways but it's rather hacky. To top it all off, I don't even know whether the firmware update fixes the problem.

Best Answer

I found the solution.

I tried fstrim with explicit statements of the partitions as a weekly cronjob shortly after I posted the answer but didn't know whether it was safe. Furthermore, I didn't know whether someone would have a better answer. Therefore, I didn't post it as an answer myself.

I just looked at the contents of the folder /etc/cron.weekly where I placed a file containing the command because I wanted to execute it manually after filling my entire disk with data today and having deleted a lot of it a few minutes ago. I didn't remember the command, so I just went where I put it. However, after executing ll I found 2 files with names leading me to believe that it was my script.

The other file wasn't put there by me so it's almost certainly delivered with Ubuntu. It's called fstrim and these are its contents:

#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true

After deleting my own script, I executed the script which came with Ubuntu because its clearly better. It felt like it took about a minute to execute which is what I'd expect from it trimming 36 GB. When I executed it a second time, it returned immediately, indicating that it did actually trim the first time.

I already sha256summed all the files in my home folder before trimming the first time, sha256summed all of them after the first trim, and found no unexpected changes (well, obviously, the contents of ~/.cache and ~/.mozilla changed as I used Firefox in the meantime) when comparing the files containing the sha256sums via Meld. I therefore concluded that it's probably safe.

Related Question