Enable automatic trimming of SSD drives

Registered by Martin Pitt on 2013-10-28

SSDs need to be TRIMed, i. e. they need to be told which blocks the OS considers as "unused" (i. e. from deleted files). Withouth this, the write speed on SSDs becomes unbearably slow over time.

http://wiki.ubuntuusers.de/SSD/TRIM explains the details, but this kind of housekeeping really should happen by default. There are two approaches to this, immediately marking the blocks as unused when deleting a file ("discard" mount option), or calling fstrim regularly. discard slows down deletion while a cronjob occasionally puts some potentially unexpected IO load on the machine, so this discussion is primarily about deciding which approach we want to do by default.

I (Martin Pitt) think that a cron approach is better. If we go with this we need to discuss when and how to run this:
 * Whats a reasonable interval (weekly/monthly/etc.)
 * How to detect devices/partitions which need trimming (/proc/mounts, hdparm -I, not mounted with "discard", etc.)

Blueprint information

Steve Langasek
Martin Pitt
Needs approval
Series goal:
Accepted for trusty
Good progress
Milestone target:
milestone icon ubuntu-14.04-alpha-1
Started by
Martin Pitt on 2013-12-17

Related branches



= Plan =
 * call hdparm -I before to know whether drive supports it; raise errors through cron if fstrim fails
 * use discard on phones
 * use benchmark to see what to do on desktop machines; see below, we will go with cron

 Cron job:
  * iterate over mounted partitions on real devices
  * ignore mounts with "discard" (could be in /proc/mounts, tune2fs if we use that)
  * check if device supports TRIM (hdparm -I for direct block devices; does not work with device-mapper)
  * call fstrim, report errors through cron mail
  * make sure it's a noop if discard is being used

Add discard option for new installs:
 * same detection logic as for the cron job

* always add the discard flag in phone images, as it will be ignored if the drive doesn't support it

Encrypted (cryptsetup) partitions:
* cryptsetup does not enable the --allow-discards option by default as by the pattern of discarded/non-discarded blocks it may be possible to conclude the type of file system (patterns of blocks) and how full the disk is; but given the dramatic write performance degradation without TRIM, that is an acceptable compromise which we need to do for our "encrypted disk, LVM" auto-partition schema.

== Plan if we would go with discard (which we don't) ===
Upgrades (if we go with discard on desktops):
* postinst snippet in util-linux to add discard mount option, same detection logic
* during that process, call fstrim once to trim already existing free blocks
* does not apply to phone, but fstab is dynamically generated anyway

Root file system handling:
* remount root file system if options in fstab doesn't match the current ones -> apply discard option
* shouldn't introduce another remount, do it at the time of -o remount,rw

[pitti] add fstab upgrade logic to add "discard" option to util-linux postinst: TODO
[stgraber] apply detection logic and discard mount option in partman: TODO
[xnox] mountall: remount root file system if options in fstab doesn't match the current ones -> apply discard option: TODO

= Links =
 * pitti's cron script: http://people.canonical.com/~pitti/scripts/fstrim
 * clauded's cron script: http://goo.gl/O8WN10
 * OpenSUSE docs: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support

= Benchmarks =

[jibel] To have a base of comparison, I benchmarked disk performance on low end hardware (ATOM N450 with a 128GB Crucial M4 SSD ) with and without 'discard'. Results: http://goo.gl/1mdjzl -- pitti: these look rather implausible (e. g. discard should not affect read speed, and there's no reason why operations with "discard" should be faster than without)

Colin King did extensive benchmarking and comparison with various scenarios. Executive summary from his findings:

== Desktop/Intel 330 SSD ==

1. discard in some cases has serious performance impact (for example,
random sized writes or mass file deletion), but performance impact in most cases is small
2. discard is less power efficient than period running of fstrim.

The hard part will be deciding how frequent to run fstrim as it depends
on the kind of write activity occurring on a system. A cron'd fstrim once or twice a week is probably sufficient, but should be made user-configurable to adjust it for particular workloads.

== Nexus 4 ==

1. discard in some cases has some performance impact (for example,
mass file deletion), but in most cases discard impact is minimal
2. I was unable to measure the power cost of fstrim vs discard, fstrim
completed too quickly to get reasonable measurements.

On the Nexus 4, there are cases where there is marginal gain and also loss
in the discard and non-discard tests cases. The differences are generally
small, so it appears that in most tests, discard being enabled does not seem
to add a noticeable overhead.

However, discard is definitely more expensive with mass file deletion. However
this does not seem to occur that often on a phone, so perhaps discard being
enabled is not such a problem.

== cost of fstrim on write operations ==

fstrim does incur a performance impact, although it is quite low. The
downside is that on a highly utilised system we have observed fstrim
running for > 10 minutes even after just a day of use.

The upside is that fstrim has been shown to be more power efficient than
constant trimming when using the discount mount option. Taking into the
consideration that a trim'd file system will overall be a few percent
more efficient, the penalty of a few % write performance lost over
several minutes during the fstrim is probably worthwhile.

Note that only 2 SSDs have been tested. The results may vary wildly with
other firmware on different SSD devices. There is a risk that some
poorly designed devices may have a larger fstrim performance impact.


Work Items

Work items for ubuntu-14.04-alpha-1:
[cking] benchmark: fstrim/discard for Nexus 4, laptop, lots of small files, big file, small and large SSD etc: DONE
[pitti] find out whether options field in fstab can be empty (for migration logic) -- they can't: DONE
[pitti] implement cron job, stick it into util-linux (http://bugs.debian.org/732054): DONE
[pitti] enable issue_discards option in lvm.cfg to clean up SSDs when removing/changing PVs (http://bugs.debian.org/717313): DONE

Work items for ubuntu-14.04-beta-2:
[stgraber] modify phone initramfs-tools to apply discard option: DONE
[xnox] for partman's auto-creation of LUKS partitioning, add "allow-discards" option to /etc/crypttab or have cryptsetup do it by default: DONE
[pitti] limit fstrim to Intel and Samsung drives by default (see bug 1259829): DONE