Saturday, 30 August 2014

Ubuntu 14.04 on an SSD

I recently upgraded my Lenovo W530 thinkpad to 14.04. As this is my primary workstation which I consider mission critical, one objective was to perform a clean install and restore my development and office environment as quickly as possible. I have set myself a target of 2 hours. The only thing considered a risk was Lotus Notes, which had to be migrated and upgraded at the same time. This post covers disk related settings I applied, and can be considered as a follow up on my two years old 'Ubuntu 12.10 on an SSD'.

I have installed Ubuntu via an UEFI bootable USB key, and during installation, reused the SSD and kept the present partition scheme.

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3E979DF9-E126-4EB8-AAF1-D17DEAD86D1E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          133119   64.0 MiB    EF00  EFI System
   2          133120        67241983   32.0 GiB    0700  Linux filesystem
   3        67241984        75630591   4.0 GiB     8200  Linux swap
   4        75630592       500118158   202.4 GiB   0700  Linux filesystem

During the installation process, all partitions except the EFI System partition have been reformatted. Later, I applied some changes to mount options.

To discard or not to discard: that is the question

Well, almost. Whether to discard or not should not be a question: in order to ensure the longevitiy of an SSD, the operating system has to communicate when unused blocks to the drive, so it can employ proper wear leveling. When to discard is the question one should ask himself, there are currently two options which are commonly used:

  • Discard as the block becomes free, that is, as part of the file delete operation. This is a mature, very safe option supported by most filesystem drivers, but impacts the performance, especially when many small files are deletes.
  • Discard all blocks that have become unused in one shot, on a scheduled basis, typically weekly. This concept is supported by some filesystem drivers (but e.g. VFAT does not support it) and is considered more performant in general, however, it can cause data loss issues on some SSDs if performed when I/O load is high. The current implementation is known to be safe on Intel and Samsung SSDs. Read more on this here

The default behavior in Ubuntu 14.04 is to run fstrim weekly via cron. The command only performs trimming on Intel and Samsung SSDs by default, and simply exits if any other SSD is found. My SSD is from Lenovo (P/N: 0A65620), and is a rebranded Samsung PM830 self encrypting disk featuring FIPS certified hardware based full disk encryption with AES-256. A quick test confirmed that my SSD is recognised as a supported device, so specifying the discard for ext4 partitions is not needed any more.

sudo fstrim -v /home
/home: 179466240 bytes were trimmed
sudo fstrim -v /
/: 59457536 bytes were trimmed

Still, partitions with VFAT or other filesytems without fstrim support should be mounted with the discard option.


I tuned the OS via sysctl variables to use swap only if really needed, as described in 'Ubuntu 12.10 on an SSD'.

# transient changes until reboot
echo 1 | sudo tee /proc/sys/vm/swappiness
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure

# persistent changes
cat <<EOF | sudo tee -a /etc/sysctl.conf

Further tweaks

I configured tmpfs to be mounted over /tmp in just the same way I did with Ubuntu 12.10, limiting the maximum size of the temporary filesystem to 25% or RAM, and adding mount options for security.

cat <<EOF | sudo tee -a /etc/fstab
tmpfs /tmp tmpfs nosuid,nodev,size=25% 0 0

Below is a verbatim copy of the bottom lines of the post 'Ubuntu 12.10 on an SSD', it still applies.

As a closing note, end-user behaviour also matters much. I try to pay attention to creating transient files under /tmp - if you compile a lot, this matters much. One should find a healthy balance between being SSD-aware and being too paranoid about it. I investigated methods to decrease disk writes caused by syslog - many suggest to mount a tmpfs over /var/log which would mean all your logs are lost when you reboot, making any kind of audit or post mortem debugging impossible. I ended up sticking to the commit=120 mount option after some calculations. You should do the math and enjoy your disk. As with any kind of disk, check the SMART attributes from time to time, and make sure you have take backups on a regular basis.

No comments:

Post a Comment