July 25th, 2008
Geek Sheet: A Tweaker’s Guide to Solid State Drives (SSDs) and Linux
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 $500-$1500 in spare change lying around? Then Solid State Drives (SSDs) are for you.
The idea of building an completely solid-state PC based on Linux intrigued me, so I called the guys over at Crucial, the mail order and memory upgrade branch of Micron Technology — and asked if they would send me a couple of SSD units to play with. Graciously, they sent me three 32GB units along with a mounting kit so I could use one of them as a removable drive.
Click on the “Read the rest of this entry” link below for more.
Right now, the cost of using 2.5″ SATA SSDs as exclusive primary storage devices is rather high, which at around $15 per gigabyte when compared with traditional mechanical disk storage is out of reach for most consumers — a typical 250GB SATA2 drive streets for about 33 to 40 cents a gig. For the most part, they’ve been relegated to executive-class ($2500 and up) ultra power-miserly and ultra-thin notebooks like the Macbook Air, Toshiba R500 and the Lenovo ThinkPad X300. Unfortunately, SSD performance on Windows is less than optimal due to the current Vista/Windows 2008 Server kernel architecture, but that doesn’t mean these babies can’t perform well on Linux and other Unix operating systems like FreeBSD.
The Crucial SSDs currently come in two models — 32GB ($499) and 64GB ($899). At that 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. Veteran Linux hacker Geoff “Mandrake” Harrison was happy to provide me with some insight from a recent O’Reilly MySQL conference in which he and his colleagues presented on how to make your MySQL machines fly using SSDs. Mandrake’s employer, The Hive recently 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.
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” 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 elevator=noop to your kernel boot parameters in your /boot/grub/menu.lst file, 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.
For example, on my test Ubuntu machine I used the following for my default kernel in /boot/grub/menu.lst:
title Ubuntu 8.04.1, kernel 2.6.24-19-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.24-19-generic root=UUID=090cbd4d-5696-4e8c-9aa5-f6e13d93f0bc ro quiet splash elevator=noop
initrd /boot/initrd.img-2.6.24-19-generic
quiet
This parameter sets the default I/O scheduler system wide, so if you have mixed SSD and conventional disks in your computer, you will want to set the scheduler on a drive-by-drive basis. This can be achieved using the following command:
echo noop > /sys/block/sda/queue/scheduler
Where “sda” is the device name of my SSD.
As with the write back caches in Tweak #1, you can make these commands persistent between reboots by adding them to /etc/rc.local.
Tweak #3: Change the file system mount options on SSDs to “noatime”. 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.
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sdb1 / ext3 noatime,errors=remount-ro 0 1
/dev/sda1 /data ext3 noatime,errors=remount-ro 0 1
/dev/sdb2 swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
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 ext2 SSDs, and you’ll be in performance hog heaven. EDIT 07-27-08: 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.
Jason Perlow is a technologist with over two decades of experience integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies. See his full profile and disclosure of his industry affiliations.
Subscribe to Tech Broiler via Email alerts or RSS.
| 07/25/08
