Solid-State Drives: Get One Already!

The final twist is write amplification. Even though the OS is sending 1MB of data, the SSD actually may be doing more writes behind the scenes for things like wear leveling and inefficient garbage collection if TRIM support isn't enabled (see the TRIM section later in this article). Most real-world write amplification values I've seen are in the 1.1 to 3.0 range, depending on how compressible the data is and how clever the SSD is at garbage collection and wear leveling.

So, how long can you expect an SSD to last for you? Longevity depends on how much data you write, and the tune2fs utility makes it really easy to estimate that from your existing filesystems. Run tune2fs -l /dev/<device>. (Tip: if you're using LVM, the stats will be under the dm-X device instead of the sdaX device.) The key fields of interest are "Filesystem created" and "Lifetime writes". Use those to figure out the average GB/day since the filesystem was created. For my laptop, it was 2.7GB/day, and for my workstation it was 6.3GB/day. With those rates, plus a rough guess for write amplification, you can estimate how much life you'd get out of any SSD.

Est. Lifespan (y) = SSDCapacity(GB) * (WriteLimit based on cell type)
                 DailyWriteRate (GB/day) * WriteAmplification * 365 (days/yr)

So if I was sizing a 256GB Samsung 840 Evo (which uses TLC cells), with a 6.3GB/day write rate and a write amplification of 3, it should give me around 37 years of service before losing the ability to write new data.

SSD Considerations for Linux


Undelete utilities work because when you delete a file, you're really only removing the filesystem's pointer to that file, leaving the file contents behind on the disk. The filesystem knows about the newly freed space and eventually will reuse it, but the drive doesn't. HDDs can overwrite data just as efficiently as writing to a new sector, so it doesn't really hurt them, but this can slow down SSDs' write operations, because they can't overwrite data efficiently.

An SSD organizes data internally into 4k pages and groups 128 pages into a 512k block. SSDs can write only into empty 4k pages and erase in big 512k block increments. This means that although SSDs can write very quickly, overwriting is a much slower process. The TRIM command keeps your SSD running at top speed by giving the filesystem a way to tell the SSD about deleted pages. This gives the drive a chance to do the slow overwriting procedures in the background, ensuring that you always have a large pool of empty 4k pages at your disposal.

Linux TRIM support is not enabled by default, but it's easy to add. One catch is that if you have additional software layers between your filesystem and SSD, those layers need to be TRIM-enabled too. For example, most of my systems have an SSD, with LUKS/dm-crypt for whole disk encryption, LVM for simple volume management and then, finally, an ext4 formatted filesystem. Here's how to turn on TRIM support, starting at the layer closest to the drive.

dm-crypt and LUKS:

If you're not using an encrypted filesystem, you can skip ahead to the LVM instructions. TRIM has been supported in dm-crypt since kernel 3.1. Modify /etc/crypttab, adding the discard keyword for the devices on SSDs:

#TargetName Device                             KeyFile  Options
sda5_crypt  UUID=9ebb4c49-37c3...d514ae18be09  none     luks,discard 

Note: enabling TRIM on an encrypted partition does make it easier for attackers to brute-force attack the device, since they would now know which blocks are not in use.


If you're not using LVM, you can skip ahead to the filesystem section. TRIM has been supported in LVM since kernel 2.6.36.

In the "devices" section of /etc/lvm/lvm.conf, add a line issue_discards = 1:

devices {
        issue_discards = 1


Once you've done any required dm-crypt and LVM edits, update initramfs, then reboot:

sudo update-initramfs -u -k all

Although Btrfs, XFS, JFS and ext4 all support TRIM, I cover only ext4 here, as that seems to be the most widely used. To test ext4 TRIM support, try the manual TRIM command: fstrim <mountpoint>. If all goes well, the command will work for a while and exit. If it exits with any error, you know there's something wrong in the setup between the filesystem and the device. Recheck your LVM and dm-crypt setup.

Here's an example of the output for / (which is set up for TRIM) and /boot (which is not):

~$ sudo fstrim / 
~$ sudo fstrim /boot 
fstrim: /boot: FITRIM ioctl failed: Inappropriate ioctl for device 

If the manual command works, you can decide between between using the automatic TRIM built in to the ext4 filesystem or running the fstrim command. The primary benefits of using automatic TRIM is that you don't have to think about it, and it nearly instantly will reclaim free space. One down side of automatic TRIM is that if your drive doesn't have good garbage-collection logic, file deletion can be slow. Another negative is that if the drive runs TRIM quickly, you have no chance of getting your data back via an undelete utility. On drives where I have plenty of free space, I use the fstrim command via cron. On drives where space is tight, I use the automatic ext4 method.

If you want to go the automatic route, enabling automatic TRIM is easy—just add the discard option to the options section of the relevant /etc/fstab entries. For manual TRIM, just put the fstrim <mountpoint> in a cron job or run it by hand at your leisure.

Regardless of whether you use the discard option, you probably want to add the noatime option to /etc/fstab. With atime on (the default), each time a file is accessed, the access time is updated, consuming some of your precious write cycles. (Some tutorials ask you to include nodiratime too, but noatime is sufficient.) Because most applications don't use the atime timestamp, turning it off should improve the drive's longevity:

/dev/mapper/baldyl-root	/  ext4  noatime,discard,errors=remount-ro 0 1