Josh Saddler

So, in between being super busy with Gentoo yet not having enough time to keep up with all the bugs, document updates, and project commitments . . . I've added yet another item to my plate: a fresh install of Gentoo onto a pair of SSDs.

I've never reinstalled Gentoo on this workstation; this is the original install from October 2006. I had thought about just finding some stage4/stage5 backup scripts and tips from the Gentoo Forums, but it seems to be more cumbersome and time-consuming than reinstalling. Besides, installing Gentoo from scratch gives me a chance to create an even more lean, minimal system. No more accumulated packages and cruft that I don't use, just the essentials.

And it'll let me see how good these SSDs really are for compilation times.

I purchased two: a 32GB Super Talent UltraDrive ME for /, and a 16GB Mobi 3000 for /var and /usr/portage.

The Super Talent is a new-generation MLC drive with an Indilinx controller. It's not as good in some areas as Intel's controller for the X-25, but it's better than everything else out there, and it doesn't have the chronic stuttering problems that all cheaper JMicron-based controllers suffer.

The Mobi is an older drive, "only" SATA-150. But it is an SLC drive, so I'll use it for the partitions that see the highest write activity, as SLC is more resilient than MLC. Plus, the contents of the drive are more or less throwaway, so if any corruption does develop, I can just replace it with no issues. /var sees log frequent writes, and there may be some Portage compilation in the tempfiles. I've been using a tmpfs on RAM for /var/tmp/portage for some time now, so I don't really think it will hit up the drive much, not with 4GB of RAM installed:

none  /var/tmp/portage tmpfs	noauto,nr_inodes=1M,size=2000M 0 0

See? A dynamic Portage compilation space, ready to occupy 2GB RAM if need be. During compiles, the only time I ever really see the HDDs light up is during the src_unpack (to RAM) and src_install phases.

So I've figured out my drive and partition usage, but the things that are causing the most headaches, and occupying the majority of my research time, are:

1. Which filesystems
2. Which mount options
3. Which schedulers
4. Partition alignment schemes

See, I will have two SSDs in there with Gentoo installed on 'em, but I'll also have a separate magnetic HDD for media storage, so that means a different for each drive.

For 1, ext4 is looking increasingly attractive for the SSDs. I may continue to use ReiserFS for the media drive, as it's worked very well for a few years now. But, given that the Portage tree is just lots and lots of tiny files, perhaps I could continue using ReiserFS on it? Though I would need to deactivate the journal. The Mobi drive should not have any journaling on it -- too many writes.

NILFS2 is another interesting filesystem, but it seems immature. BtrFS also has potential, especially after reading Val's excellent article, but its developers warn against using it for anything other than testing. So I'll stick with something a little more mainstream, yet not so old and cranky as ext3/ext2.

Which brings me to 2: mount options. I've only just begun to read up on suggested options for ext4. data=writeback seems to be one of the more popular suggestions. noatime is a necessity; I've used this option on every single Gentoo install I've ever had. There are several other options I need to investigate, including the dir_index variations.

If I go with ReiserFS, I'd need to research the performance differences between notail and tail. In theory, the latter option could be more efficient for packing more data into fewer blocks, resulting in fewer writes/rewrites. This is at the expense of slightly more CPU usage. notail may result in more speed, but I haven't found many detailed reports of ReiserFS usage on SSDs. One last thing to look up would be the difference between ReiserFS with the journal and without.

The next piece of the puzzle is 3, schedulers. Most of the schedulers in the kernel are designed to keep spinning magnetic disks happy. But since there aren't any moving heads or rotating disks to spin up, the algorithms that are designed for efficient, minimal motion aren't very helpful for SSDs.

The usual solution proposed is to bypass the traditional HDD seek layer overhead by just using the noop scheduler. It's a very simple FIFO-based scheduler. System requests a file, it gets it. No complex queuing up done in the kernel. It lets the extremely fast drive controller do all the work, since it's capable of getting the data where it's needed without stuttering or delays.

However, the deadline scheduler may be as good as noop, as deadline does a certain amount of prioritizing. My understanding is that it's similar to NCQ in this regard, and that using deadline doesn't have any overhead costs. Still doing the research on this.

These two schedulers may be all well and good for the SSDs, but since I'll have two SSDs, a magnetic hard drive, and an optical drive in my box, I can't use the same scheduler for all of 'em. noop would be a poor choice for the HDD, so I may use deadline or stick with the tried-and-true CFQ scheduler.

Fortunately, using different schedulers for different drives is fairly easy:

# echo deadline > /sys/block/sda/queue/scheduler
# echo noop > /sys/block/sdb/queue/scheduler
# echo cfq > /sys/block/sdc/queue/scheduler

It's just a matter of putting these commands into an initscript to be run at boot.

The last puzzle piece (so far) is 4, partition alignment schemes. This is the most confusing one. The most headache-inducing. The most worrisome one, in that if I screw it up, I could completely hose the performance of the drives, and severely impact the wear and tear on the drive.

The OCZ Vertex is functionally identical to the Super Talent UltraDrive. Same controller and firmware, so Vertex tips will apply to my drive. The OCZ forums have proven rather useful. There's a fair amount of material at the OCZ forums, and even some suggestions by Gentoo users. Unfortunately, some of the threads are rather old, so I'm unsure how much still applies. Given that there have been new hardware revisions, new firmware shipped with the drives, and improvements to the Linux kernel stack (schedulers, libata, etc.).

Ted Ts'o has a pretty good explanation, but it differs from some of the other suggested block sizes. Also, some guides have a radically different approach.

* * *

So, four pieces to the Gentoo installation on an SSD puzzle. Lots of notes so far, and despite four months' research, I feel like I've barely gotten started. I've been thinking and planning to move to an SSD for quite awhile now; it's mostly been a matter of waiting for prices to fall. Now all the components are here, so I'll just have to dive right in and see what I find. Results will, of course, wind up here.