Enable automatic trimming of SSD drives

= 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

Phone:
* 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 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