title: Is it trim... ming? link: https://onemoretech.wordpress.com/2014/04/23/is-it-trim-ming/ author: phil2nc description: post_id: 7432 created: 2014/04/23 15:12:24 created_gmt: 2014/04/23 19:12:24 comment_status: closed post_name: is-it-trim-ming status: publish post_type: post

Is it trim... ming?

If you're running Linux on a commodity SSD drive, you'll want to know if TRIM is enabled. Most of use are moving to SSDs for two reasons. First, SSDs are a lot faster than Hard Disk Drives (HDDs). Second, SSDs can potentially last longer than HDDs because SSDs have no moving parts to wear out, and don't generate the kind of heat that's the enemey of all electronics. SSDs are also immune to the effects of file fragmentation. But SSDs do wear out. The individual cells where data is stored can only be written to/erased from a finite number of times. Modern SSDs are programmed to avoid unnecessary write/erase operations. SSDs also differ from HDDs in that HDDs will usually directly overwrite blocks that the operating system has marked as invalid (for example, when data is deleted), but SSDs instead first re-allocate a block marked as invalid to a new location. Unless the SSD is told otherwise, the old data is not actually deleted and continues to take up space. A discard request (implemented as the TRIM command on ATA devices, WRITE_SAME with UNMAP and UNMAP on SCSI devices) tells the SSD which blocks of data are no longer in use and can therefore be erased. This helps avoid costly re-allocations and therefore preserves the life of the drive. Like most newer Linux distributions, Red Hat Enterprise Linux 6+ and corresponding Fedora releases support discard operations on compatible hardware. To check on whether discard is supported on system disks, use the lsblk command:

[root@bigserv ~]# lsblk -D
NAME            DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                    0      512B       2G         0
├─sda1                 0      512B       2G         0
└─sda2                 0      512B       2G         0
  ├─fedora-swap        0      512B       2G         0
  ├─fedora-root        0      512B       2G         0
  └─fedora-home        0      512B       2G         0
sdb                    0        0B       0B         0
└─sdb1                 0        0B       0B         0
  └─md0          1048576        1M       0B         0
    └─vg1-data         0        1M       0B         0
sdc                    0        0B       0B         0
└─sdc1                 0        0B       0B         0
  └─md0          1048576        1M       0B         0
    └─vg1-data         0        1M       0B         0
sdd                    0        0B       0B         0
└─sdd1                 0        0B       0B         0
  └─md0          1048576        1M       0B         0
    └─vg1-data         0        1M       0B         0

A non-zero value in the DISC-GRAN and DISC-MAX columns indicates that the O/S and device support discards. In the above example /dev/sda is a 64GB SSD boot drive, while sdb, sdc and sdd are 3 traditional mechanical disk drives in a RAID configuration. Note that LVM is being used on all partitions except for /boot (that's /dev/sda1). In their latest Storage Administration Guide for the RHEL 7 Beta, Red Hat makes a distinction between "batch discard operations" and "online discard operations". Batch operations are performed using the fstrim utililty, usually in a cron job. Online operations are done automatically as soon as a block is marked as invalid if the disk has been mounted using the special "discard" directive. This is what it looks like when you run fstrim on an SSD after a few months in operation:

[root@bigserv ~]# fstrim -v /
/: 18 GiB (19294052352 bytes) trimmed

[root@bigserv ~]# fstrim -v /home
/home: 7.3 GiB (7793635328 bytes) trimmed

Red Hat (and many others) recommend using batch discard operations rather than online operations due both to compatibility issues with some hardware, and degraded performance when using the latter method (batch jobs can be scheduled to occur when no one is using the system). Here's a nice blog post by Carlos Perez outlining one possible implementation. A simple script to run out of /etc/cron.weekly, lifted from Carlos's post:

#! /bin/sh
# /etc/cron.weekly/trimssd
for mount in / /boot /home; do
	fstrim $mount
done

Copyright 2004-2019 Phil Lembo