The Trim Command

Most SSDs support a command that tells the device which data blocks are no longer in use. SSDs cannot simply overwrite data like traditional hard disks but need to explicitly delete the old data up front, which is exactly what the trim command does; you can imagine this as being a kind of internal garbage collector that tells the controller about the data areas no longer in use.

If you were to do without trim, the controller would initially be unable to reuse areas that are marked re-writable at filesystem level [2]. At the same time, the controller would continue to include parts of already deleted data in its garbage collection and thus do unnecessary work.

The discard mount option, which originates from the beginning of the SSD era, is equivalent to an automatic trim after file operations. Today, batched discard, as offered by tools such as fstrim, is the preferred method. The use of discard as a mount option is now discouraged.

In practice, a trim is not a trivial task; discarding the wrong data areas leads to data loss. And such problems do actually occur from time to time. Theodore Ts'o, the main developer of Ext4, thus explicitly advises against using discard as a mount option. Under high I/O loads, many SSDs would tend to discard the wrong blocks. The performance penalties for deletions with discard enabled are not as serious as data losses.

Each level of the I/O stack must support trim – from the filesystem, through the block layer, to the SSD device. Linux software RAID with mdraid, for example, supports trim as of kernel version 3.7. But bugs make the user's life difficult: For example, users of RAID 0 with kernel 4.0.2 might remember headlines about a problem with losing data.

At the SATA level, a queued trim option evolved during trim's on-going development, which promised better performance but put pressure on some prominent SSD manufacturers supporting Linux. The libata source code has a black list of manufacturers who disabled the queued trim commands. All told: It is wise to do without trim if you are using consumer SSDs.

If you want to be on the safe side with your SSD, over-provisioning is the way to move forward. If you use a hardware RAID controller, trim is not an option anyway, because it will not pass the trim commands through to the attached SSDs. Otherwise, you would need to invest a huge amount of time researching the SSD firmware, the I/O stack, and the kernel version.

At server and enterprise level, SSDs have a larger gross capacity out the box and thus compensate for the lack of trim. fstrim is useful for workloads with high proportions of create and delete operations. If you prefer to do without trim, you should still keep in mind that some Linux distributions – including Ubuntu version 14.04 – set up cron jobs that automatically run fstrim.

Barriers

Many websites sing the praises of the nobarrier mount option as a tuning measure. Barriers ensure that the filesystem stays in a consistent state in case of a power outage. The nobarrier option can now accelerate file access by removing the synchronization overhead. Several tutorials rely on the fact that nobarrier is safe if the SSD has power loss protection (PLP). PLP is basically a capacitor that momentarily provides the device with energy in case of an outage. The SSD's write cache is thus still flushed to the flash chips.

One thing is for sure: Without PLP, the user definitely needs to leave the barriers option switched on in order to avoid jeopardizing data consistency. Christoph Hellwig, one of the main developers of XFS, still advises on using nobarrier – even if the disk has PLP. His argument: If a device does not need to flush the cache, it will not request to do so, and then nobarrier will do nothing. And vice versa: If nobarrier makes a difference, it is not safe to leave it out.

relatime, lazytime, and noatime

The noatime option is no longer considered a must-have for SSDs. On Linux, each file operation updates the access time (atime) of the file. The noatime mount option omits this step, thus saving write ops. But some programs rely on an atime update and do not work with noatime. Two new mount options therefore combine performance with functionality and make noatime superfluous: relatime became the default setting in kernel 2.6.30. The relatime option tells Linux to only update the atime if the file has changed. lazytime is a new option in kernel 4.0. lazytime keeps updates in RAM that are flushed later along with other changes.