Install a new drive, format, partition and mount it, for example as: “/ssd”
- It is recommended that the SSD drive be setup in EXT4 format.
- EXT4 format supports TRIM when used with “discard” mount option.
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to set up SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux.
Note: This article is targeted at users running Linux, but much of the content is also relevant to our friends using other operating systems like BSD, Mac OS X or Windows.
Advantages over HDDs
- Fast read speeds – 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).
- Sustained read speeds – no decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.
- Minimal access time – approximately 100x faster than an HDD. For example, 0.1 ms (100 us) vs. 12-20 ms (12,000-20,000 us) for desktop HDDs.
- High degree of reliability.
- No moving parts.
- Minimal heat production.
- Minimal power consumption – fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.
- Light-weight – ideal for laptops.
- Per-storage cost (close to a dollar per GB, vs. around a dime or two per GB for rotating media).
- Capacity of marketed models is lower than that of HDDs.
- Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.
- Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.
- Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.
- Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They implement the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.
- Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.
There are several key features to look for prior to purchasing a contemporary SSD.
- Native TRIM support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.
- Buying the right sized SSD is key. As with all filesystems, target
This section is not meant to be all-inclusive, but does capture some key reviews.
- SSD Anthology (history lesson, a bit dated)
- SSD Relapse (refresher and more up to date)
- One user’s recommendations
- Enabling and Testing SSD TRIM Support Under Linux
Tips for Maximizing SSD Performance
Using partitions that are aligned with the erase block size is highly recommended. In past, this required manual calculation and intervention when partitioning. Many of the common partition tools handle partition alignment automatically (assuming users are using an up-to-date version):
To verify a partition is aligned, query it using
/usr/bin/blockdev as shown below, if a ‘0’ is returned, the partition is aligned:
# blockdev --getalignoff /dev/ 0
Most SSDs support the ATA_TRIM command for sustained long-term performance and wear-leveling. For more including some before and after benchmark, see this tutorial.
As of linux kernel version 3.7, the following filesystems support TRIM: Ext4, Btrfs, JFS, and XFS.
The Choice of Filesystem section of this article offers more details.
Verify TRIM Support
# hdparm -I /dev/sda |grep TRIM * Data Set Management TRIM supported (limit 1 block) * Deterministic read data after TRIM
To have a better understanding of “limit 1 block” or “limit 8 block”, see wikipedia:TRIM#ATA
Enable TRIM by Mount Flags
Using this flag in one’s
/etc/fstab enables the benefits of the TRIM command stated above.
/dev/sda1 / ext4 defaults,noatime,discard 0 1 /dev/sda2 /home ext4 defaults,noatime,discard 0 2
discardflag for an ext3 root partition will result in it being mounted read-only.
discardflag. Data loss can occur otherwise!
Apply TRIM via cron
Enabling TRIM on supported SSDs is definitely recommended. But sometimes it may cause some SSDs to perform slowly during deletion of files. If this is the case, one may choose to use fstrim as an alternative.
# fstrim -v /
The partition for which fstrim is to be applied must be mounted, and must be indicated by the mount point.
If this method seems like a better alternative, it might be a good idea to have this run from time to time using cron. To have this run daily, the default cron package (cronie) includes an anacron implementation which, by default, is set up for hourly, daily, weekly, and monthly jobs. To add to the list of daily cron tasks, simply create a script that takes care of the desired actions and put it in
/etc/cron.weekly, etc. Appropriate nice and ionice values are recommended if this method is chosen. If implemented, remove the
discard option from
discardmount option as a first choice. This method should be considered second to the normal implementation of TRIM.
Enable TRIM for LVM
issue_discards option in
Enable TRIM With mkfs.ext4 or tune2fs (Discouraged)
One can set the trim flag statically with tune2fs or when the filesystem is created:
# tune2fs -o discard /dev/sdXY
# mkfs.ext4 -E discard /dev/sdXY
discardoption to not show up with
1. Change directory to new partition/location
# cd /
Create new ssd directory.
# mkdir ssd
mount the ssd
|# cd /ssd|
2. Create new MySQL directory.
3. Assign the MySQL group and owner for the new data directory.
|# chown -R mysql:mysql /ssd/mysql|
4. Shutdown the MySQL server.
|# /etc/init.d/mysql(d) stop|
- In Cpanel servers, stop chkservd too, else MySQL will be restarted, if monitoring is enabled.
5. Sync all the databases from old data dir to new data dir.
|# nohup rsync -vrplogDtH /var/lib/mysql/ /ssd/mysql &|
(nohup insures that the copy command runs even if the shell hangs and the sync status will be available in nohup.out)
6. Once you have verified the data, delete the “/var/lib/mysql” folder.
* It is recommended that you back this up on another partition first! *
* If you have enough space in /home you can move the old mysql data untill you verfiy it.*
# mv /var/lib/mysql /home/oldmysql
Or you can rename it
# mv /var/lib/mysql /var/lib/mysqlold once verfied you can remove it.
|# rm -rf /var/lib/mysql|
7. Create a symbolic link from the new data directory to the old one.
|# ln -s /ssd/mysql /var/lib|
Note: Create a symlink to avoid changing the MySQL socket and data path in MySQL, PHP and other applications that need it.
8. Turn on the mysql service
#chkconfig mysql on
9. Restart the server to make sure all the cache is cleared out and mysql loads correctly.
You must log in to post a comment.