Improve SSD performance with fstrim

It seems that SSD performance decreases over time, since unlike hard disk drives (HDDs), NAND flash memory that make SSD cannot overwrite existing data. This means that you first have to delete the old data before writing new one.

Flash memory is divided into blocks, which is further divided in pages. The minimum write unit is a page, but the smallest erase unit is a block. This means that as time goes on, the SSD will internally fragment the blocks among the different pages, until that it reaches a point where there won’t be available any empty page. Then every time the drive needs to write a block into any of the semi-full pages, it first needs to copy the current blocks from the page to a buffer, then it has to delete the whole page to finally rewrite the old blocks along with the new one. This means that as time goes on the SSD performance degrades more and more, because for every write it has to go through a cycle of read-erase-modify-write. This is known as “write amplification”.

TRIM was invented for solving this problem, allowing the operating system to tell the SSD which blocks are free in the filesystem. The SSD uses this information to internally “defragment” the blocks and keep free pages available to be written quickly and efficiently. However, before proceeding further, you should check that your system supports TRIM by running this command (replace /dev/sda with your SSD):

:~$ sudo hdparm -I /dev/sda | grep "TRIM supported"

If everything is ok, you should receive the following response:

* Data Set Management TRIM supported (limit 8 blocks)

There are currently two ways to TRIM, either by adding an extra option called “discard” to the disk entry in /etc/fstab, or by using the command fstrim. Using fstab means that every time you delete a file, the OS will be reporting in real-time to the SSD which blocks were occupied by that file and are not longer in use, and then the SSD will have to perform a defragmentation and deletion of those internal blocks, operation which will take an amount of time higher than desired. Additionally, since trimming takes place as soon as you delete a file, there is no way to recover it anymore!

Instead, you can run a script periodically to tell the SSD which blocks are free with the command fstrim. Depending on how many writes/deletes you normally perform, doing this operation as part of a daily or weekly cron job is more than enough. In this case, if you delete a file before the cron job takes place, you will probably be able to recover it. Here are the steps you need to take to enable regular trimming on your machine.

First, create a new file that will hold the script for the cron job:

:~$ gksu gedit /etc/cron.daily/trim

And then paste the following lines:

echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG

You can now make the script executable by running this command:

:~$ sudo chmod +x /etc/cron.daily/trim

That’s it. If you really want to rest that it is running, you can use this command:

:~$ sudo /etc/cron.daily/trim && cat /var/log/trim.log

You should then see something like this:

*** Thu, 12 Sep 2013 16:42:39 +0200 ***
/: 814514176 bytes were trimmed




  1. this changelog doesnt works whit ini.d kernel, i only have a response like this:

    * Data Set Management TRIM supported (limit ase)

  2. I did not like that i had to decide for example today to put my script into e.g. /etc/cron.weekly and in a week it would better suite into /etc/cron.hourly. So i made a semi automatic script which every time it is started automatically decides where it should be put. Maybe you want to give a look at github ( It is (hopefully) distribution independent so it should also work on Ubuntu…

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>