How to check TRIM

I think the major misconception here is that issuing TRIM will cause the blocks to be erased then and there. Really all that the TRIM command is doing is informing the SSD that the OS no longer needs the data at this location, exactly what happens after that is up to the firmware Ideally the firmware should use this information to:

1. Avoid copying and re-writing this data when another part of the block is rewritten. Remember that the erase block size for an SSD is (always?) larger than the write block size, so when it has to re-write a particular block, it will often have to copy a larger area, erase and re-write the larger area with the updated data included. If a TRIM has been issued for part of that area, this part it does not have to be copied or rewritten. This is faster and prevents unneeded writes which will shorten the life of the device.

2. Perform other wear levelling optimisations.

Neither of these require that the data be erased straight away. In fact, it may be better for the SSD's lifespan if this doesn't happen when the trimmed area is less than the size of an erase block. That said, it also follows that it may be good practice for the SSD to erase the areas that cover full erase blocks soon after the TRIM is issued.

If you have had success with the above method before, it may have been that the SSDs used had a smaller erase block size. Unfortunately the manufacturers rarely publish this data, but digging around, 512k doesn't seem to be unheard of. You may have success if you try reading and writing a larger area which would cover several erase blocks and reading from the middle of the area rather than the start or end, since the first part may not get its own erase block.

However note that I had the same result as the question even with an 16 MiB continuous block.

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.