Este conteúdo não está disponível no idioma selecionado.
Chapter 21. Solid-State Disk Deployment Guidelines
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).
Enabling
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 4.7.3.4 of the SCSI Block Commands 3 T10 Specification from the following link:
Note
Not all solid-state devices in the market have
discard support. To determine if your solid-state device has discard support check for /sys/block/sda/queue/discard_granularity.
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.
Note
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 mismatched/inconsistent.
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 mount option discard. For example, to mount /dev/sda2 to /mnt with 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.
