Performance degrades as the number of used blocks approaches the disk capacity. The degree of performance impact varies greatly by vendor. However, all devices experience some degradation.
To address the degradation issue, the host system (for example, the Linux kernel) may use discard requests to inform the storage that a given range of blocks is no longer in use. An SSD can use this information to free up space internally, using the free blocks for wear-leveling. Discards will only be issued if the storage advertises support in terms of its storage protocol (be it ATA or SCSI). Discard requests are issued to the storage using the negotiated discard command specific to the storage protocol (
TRIM command for ATA, and
WRITE SAME with
UNMAP set, or
UNMAP command for SCSI).
discard support is most useful when there is available free space on the file system, but the file system has already written to most logical blocks on the underlying storage device. For more information about
TRIM, refer to its Data Set Management T13 Specifications from the following link:
For more information about
UNMAP, refer to section 22.214.171.124 of the SCSI Block Commands 3 T10 Specification from the following link:
Not all solid-state devices in the market have
discard support. To determine if your solid-state device has
discard support check for
21.1. Deployment Considerations
Because of the internal layout and operation of SSDs, it is best to partition devices on an internal erase block boundary. Partitioning utilities in Red Hat Enterprise Linux 6 chooses sane defaults if the SSD exports topology information.
However, if the device does not export topology information, Red Hat recommends that the first partition be created at a 1MB boundary.
As of Red Hat Enterprise Linux 6.5 MD MD now supports passing discard requests. Prior to 6.5, it was not supported. In contrast, the logical volume manager (LVM) and the device-mapper (DM) targets that LVM uses do support discards. The only DM targets that do not support discards are dm-snapshot, dm-crypt, and dm-raid45. Discard support for the dm-mirror was added in Red Hat Enterprise Linux 6.1.
Red Hat recommends the use of RAID1 or RAID10 for LVM RAIDs on SSDs as these levels support discards. During the initialization stage of other RAID levels, some RAID management utilities (such as
mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.
It is possible to use
--nosync option on RAID1, RAID10, and parity RAIDs as parity will be calculated for that stripe the minute the first write is made, therefore remaining consistent. However, when performing scrubbing operations, the portions that have not been written will be counted as
As of Red Hat Enterprise Linux 6.4, ext4 and XFS are the only fully-supported file systems that support
discard. Previous versions of Red Hat Enterprise Linux 6 only ext4 fully supported
discard. To enable
discard commands on a device, use the
discard. For example, to mount
discard enabled, run:
# mount -t ext4 -o discard /dev/sda2 /mnt
By default, ext4 does not issue the
discard command. This is mostly to avoid problems on devices which may not properly implement the
discard command. The Linux
swap code will issue
discard commands to
discard-enabled devices, and there is no option to control this behavior.