TRIM facepalm

2015/11/19 by Tomas Vondra

While discussing results of various filesystem benchmarks - both here and in talks given on conferences, one of the things I've been questioning was the negligible impact of TRIM/DISCARD mount option.

I was speculating that maybe TRIM only really matters when the drive gets almost full, because until then the controller has enough room where to write the incoming data without getting the internal garbage collection under pressure. But I've recently did a a few pgbench runs aiming to test exactly this, using a rather large scale (filling more than 90GB of the 100GB drive), yet still no diference.

Another speculation was that maybe this particular SSD is really good and there's so much additional overprovisioning that the TRIM still makes no difference. After all, it's a good SSD frin Intel (S3700) meant for write-intensive data center applications, so I wasn't entirely surprised by that.

But then it dawned upon me ...


The TRIM does not matter because pgbench does not discard any pages, it simply overwrites the pages in place, so there's nothing to TRIM.

What pgbench does is that (a) it writes new data by adding new pages and (b) updates those pages, by rewriting them in place. None of that involves discarding pages - the controller knows which page of the file it's overwriting, and therefore knows which SSD pages are dirty and need to be erased. Similarly for WAL segments, that are reclaimed and overwritten in-place.

Maybe the TRIM does matter for other workloads (e.g. creating a lot of temporary files on the SSD device), or in databases where tables are often dropped or truncated. But for the simple pgbench workloads, TRIM does not matter at all.

comments powered by Disqus