Editor's note: this post was originally published in July of 2008. It's been updated with current information.
Is 20th century conventional Winchester multi-platter, multi-head random-access disk technology too quaint for you? Want to run your PC or server on storage devices that consume far less energy than the traditional alternatives? Want a portable or mobile storage unit that will never fail due to G-forces or "crashing?". Looking for a highly reliable and fast random access storage medium to use for your most important data? Do you have $250.00-$500.00 in spare change lying around? Then Solid State Drives (SSDs) are for you.
Right now, the cost of using 2.5" SATA SSDs as exclusive primary storage devices is rather high. At around $240.00-$250 for one of the higher-performing 120GB units when compared with commodity pricing on traditional mechanical disk storage, SSDs are out of reach for most consumers as bulk storage at $2 per Gigabyte -- 1TB hard disks can now be found for as little as $60-$75 each, with an approximate price of 6 cents per Gigabyte.
For the most part, they've been relegated to executive-class ultra power-miserly and ultra-thin notebooks like the Macbook Air and other high-end business class notebooks running on Windows. But that doesn't mean these babies can't perform well on Linux and other Unix operating systems like FreeBSD, and can be an easy way to boost performance of your system provided that you don't use them as your primary storage device.
At their $2 per GB price point, unless you are really rolling in cash, you probably don't want to be stuffing these with anything less than mission-critical data. SSDs perform exceedingly well for things like MySQL databases, provided you tweak your kernel, BIOS, and filesystems accordingly. They're also excellent for boot drives, root filesystems, and storing small VM files. For example, I run my Ubuntu Linux 10.10 boot drive and a 20GB Windows XP VM on mine, a 120GB OCZ Vertex 2.
When this piece was originally posted in 2008, Veteran Linux hacker Geoff "Mandrake" Harrison was happy to provide me with some insight from an O'Reilly MySQL conference in which he and his colleagues presented on how to make your MySQL machines fly using SSDs. Mandrake's employer at the time had spent an obscene amount of money on SSDs, and he was happy to brag about how much power they are saving and the performance they are getting out of them relative to good old SATA2 disk units.
Also See: MagicFab SSD Checklist (Ubuntu.com)
Tweak #1: If your system motherboard uses a disk caching bus, change the BIOS setting from "Write Through" to "Write Back". The standard practice on Linux with conventional drives is to set it as "Write Through" but the simpler architecture of an SSD results in poorer performance with this default setting. Once you've enabled it in the BIOS, you can set this on a drive by drive level by executing this command as the root user:
[root@techbroiler ~]# hdparm -W1 /dev/sda
Similarly, if you have conventional drives in your system in addition to SSDs, you can issue a:
[root@techbroiler ~]# hdparm -W0 /dev/sda
To disable write-back caching.
To make these changes persist between reboots, add the commands to the /etc/rc.local file.
Tweak #2: Use the "noop" simple I/O scheduler. By default, Linux uses an "elevator" so that platter reads and writes are done in an orderly and sequential matter. Since an SSD is not a conventional disk, the "elevator" scheduler actually gets in the way.
By adding block/sda/queue/scheduler = noop to your /etc/sysfs.conf (requires the sysutils package) or elevator=noop to the kernel boot parameters in your /etc/default/grub file (assuming you are only using one SSD) you will greatly improve read and write performance on your SSD.
For those of you using Linux in virtual machines on conventional drives such as JBOD and SAN-based arrays, this is a good practice as well, since most VMs are implemented in image files (such as .vmdk on VMWare and .vhd on Hyper-V) and there is no need to treat I/O to a virtual disk the same as a physical one.
Tweak #3: Change the file system mount options on SSDs to "noatime" and mount your /tmp in RAM. On certain Linux distributions, such as Ubuntu, the default is "relatime". This tells the kernel to write the Last Accessed Time attribute on files. Conversely, "noatime" tells the kernel not to write them, which considerably improves performance. Linus himself suggests using it in circumstances such as this, so therefore, I consider it to be gospel. Here's what my /etc/fstab looks like.
UUID=aaf49668-2624-4238-a486-baf341361be6 / ext4 noatime,discard,data=ordered,errors=remount-ro 0 1
tmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777 0 0
Note that I have set data=ordered as opposed to data=writeback, which you would use if you formatted the drive with ext2 instead of ext4 or another journaled FS. In my case, I'm using ext4, mounted fully journalized, so this is a good compromise.
Additionally, because I have a large amount of RAM on my system (16GB) I've moved the temp file system into RAM as opposed to running it on disk. This also creates a significant performance boost and reduces unnecessary writes to the SSD. If you have at least 4GB of RAM, this is a good idea.
Tweak #4: Ditch the journal and RAID your SSDs. File system journaling is done primarily for increased reliability, but it's a drag on performance. Given that SSDs by their nature are going to be less prone to reliability quirks than a conventional drive, Mandrake suggests creating a RAID1 of two SSD units and formatting the file system to ext2, or formatting them to ext3 and mounting them as ext2 in the /etc/fstab.
Dump your MySQL database on a RAID of SSDs, and you'll be in performance hog heaven.
[EDIT 11/19/2010: It has been suggested in the comments that formatting the filesystem as ext4 and mounting with the journal enabled and RAID1 may actually be faster than ext2 RAID1 and provide additional referential integrity, and mounting a ext4 RAID1 in unjournalized mode may also be faster than ext2 RAID1. Your mileage may vary.]
[EDIT 07/27/2008: Some concerns were raised about what could happen if the power goes out and you lose referential integrity of the FS and are unable to replay it from the journal -- so you might want to use a traditional disk using a journaled FS to sync the database to for backups.]
Gonna mortgage your house or send your children into slavery for sweet SSD love? Talk Back and let me know.