The Solid State Drive (SSD) has been in the system for over a week now, so here’s an update on it:

It’s FAST!

Okay, that’s not news, but I felt compelled to say it anyway. 😉

After letting the Linux VM run for several days with memory-hog programs like Firefox (with about a dozen pages open) going, and developing code for at least a few hours each day, free memory was getting pretty low. When that happened previously, I’d start getting massive delays when I tried to compile things, with tools indicating that the system was waiting for the hard drive (“IOWait”). As I’d hoped but didn’t dare expect, those delays are GONE! Every compile is equally fast now, whether the first one after a reboot (which I’d previously clocked at taking nearly four minutes) or the twentieth, with several gigabytes free or only one! I can barely see any IOWait delays at all, in action or even on the monitoring program!

I’d REALLY like to move the system drive of the Windows VM over too, but as mentioned before, that would take a reinstall of the OS and a lot of time that could be much better spent writing code. The Windows VM doesn’t seem to suffer nearly as much from low-memory-induced compile delays anyway, so as nice as that would be, it can wait a while longer.

I can definitely see why people recommend SSDs for their speed, despite their well-documented longevity problems. Now if this one will only last for a few years…

Both the new Solid State Drive (SSD) and the Data Doubler mounting bracket arrived way ahead of schedule — on Thursday afternoon, in fact, a day early for the Data Doubler and at least four days early for the drive itself. I’m not complaining. 🙂

The drive was in OEM packaging, meaning that it was meant for system builders rather than consumers (it’s slightly cheaper that way, for those of us who just need the drive). OEM packaging doesn’t include any fancy extras like cables, mounting brackets, instruction manuals, or spare screws, and this one was no exception… well, with one exception. It was amusing to find the one extra thing that was included in the tiny box:

Nothing like asking your system manufacturers to do a little advertising for you, eh Intel?

The Data Doubler was smaller than I’d subconsciously expected, but otherwise identical to the pictures. A good sturdy mounting bracket, along with all the tools and screws needed to install it. The instructions were good, I had very little trouble getting it installed. It took about twenty or twenty-five minutes, but future ones would probably only take ten to fifteen. Apparently something got reassembled a little wrong on the first try, because the speaker sounded very tinny after that, but opening it up and poking around again fixed it somehow. Maybe it just liked me. 😉

The external drive enclosure was less than impressive though. The company I’d ordered the Data Doubler from didn’t have the companion OWC “SuperSlim” enclosure, so they sent a StarTech “USB to Slimline SATA CD/DVD Optical Drive Enclosure“. It’s essentially a four-sided metal box with a plastic insert to hold the drive and a plastic back, held together with two screws.

The plastic insert didn’t want to come out of the metal case; as it turns out, the back had an internal plastic catch holding it in, as well as the aforementioned two screws. Once it was out, you’re supposed to be able to mount the optical drive onto the plastic insert with two more small screws, but the holes in the insert didn’t line up with those in the drive at all… it took some patient work with a pocketknife before they’d fit. With it all reassembled, the industrial-looking and very unaesthetic front of the drive mechanism is very obvious, with no attempt made to cover it or make it look nice. It works, and it’ll do since the drive is rarely needed, but that part of the conversion was very disappointing.

Once the drive was installed and partitioned (into a large partition and a small 10GB one, which will remain unused to ensure that the drive never gets completely full — see the earlier post for the reason), it was time for the hard part: the software.

The sites that recommend this conversion diverge at this point. Some of them use a program called Carbon Copy Cloner to duplicate the existing OS onto the SSD, leaving a few directories behind; others suggest installing a fresh copy of the OS and using symlinks to point a few directories to the original drive (“the data drive” from here on). Both usually recommend deleting the OS from the target drive too. I chose the fresh-copy route (which may have caused more minor headaches than it prevented), and left the OS intact on the data drive, so if (or when) the SSD fails, there will still be a working OS install to boot from.

The Migration Assistant program copied the programs and settings over without any problem, but I told it to leave the user directories and “other files and folders” alone — other than the OS, almost everything is going to stay on the data drive.

The plan was to replace every non-static directory with symlinks to the data drive. It didn’t work; the system apparently panics if you try to use symlinks to a different drive for any of its directories, and will refuse to finish booting. The end result was that the only things I could symlink were the items in the Users directory for my username. Annoying, but it works, for now.

As may have been mentioned before here, few Mac OS programs get used on this system, and those few reacted to the move very differently:

• iTunes, used to back up my iPod Touch, copied over fine. A few symlinks restored its music files and other data, which remained on the data drive.
• The address book and calendar programs, used because they offer a convenient way to access the address and calendar data from the Touch, didn’t retain any of their data. Fortunately, a single sync of the Touch restored it.
• Skype (the Mac OS version is needed because virtual machines don’t run it very well) had to be told my username and password again, and forgot my conversations, though that wasn’t a major problem.
• MenuMeters, needed because even the non-SSD hard drive is too quiet for a control freak like me to tell when it’s active, didn’t copy over at all. It appeared in the System Preferences panel, but gave an error message when trying to start it. Reinstalling and reconfiguring fixed that.
• Things, the program that presently keeps track of my to-do lists, had complete amnesia (not Ambrosia 😉 ). Fortunately most of its data is stored on the iPod Touch as well as on a remote server, so re-entering the username and password gave it enough info to recall everything except that it had been purchased. Re-entering the purchase key fixed the rest.
• Parallels (for running Linux and Windows virtual machines) recalled everything except where its virtual machine files actually were. A symlink to the old profile’s Documents folder fixed that one.

The last thing needed was tweaking the OS configurations for the SSD.

The most important was Mac OS, since it’s the host system and interacts directly with the drive. Fortunately it has had several SSD-related updates in the last few years, to support SSD-specific things like TRIM, so there wasn’t much to do to it, other than setting noatime, turning off “Smart Sleep”, and disabling Spotlight (not necessary, but I don’t use it). Those three items will greatly reduce the number of writes needed on the SSD. Many sites also recommend disabling hard drive sleep and the sudden-motion sensor, but those suggestions are apparently due to some bugs in earlier versions of Apple systems; this one doesn’t appear to need either, and the sudden-motion sensor is very important on a laptop like this one for the non-SSD drive.

The Linux VM was already set up with separate virtual drives for the system and the home directory, so there wasn’t much needed there. Essentially just setting noatime (much easier than on the Mac), and moving /tmp and /var/tmp to the data drive via symlinks (not to RAMdisk like that page suggests, RAM is precious on this system, no matter how much it has). The scheduler and Firefox cache weren’t changed because it wasn’t necessary with this particular setup (virtual machines running on both SSD and magnetic media).

There’s plenty to do on the Windows 7 VM, but that one may not get done for a while. It’s not set up with a separate system drive at present, so it will probably require a fresh reinstall of the OS (meaning reinstalls of all my tools and utilities too)… that’s a two-day job at best, so it’s getting put off until the next time I’m forced to reinstall the OS for other reasons.

With all of that done, here are the new timings, using the same setup as in the previous report:

• Cold-boot the Mac: 0:30 (0:24 + 0:06, a savings of 53 seconds)
• Cold-boot the Linux virtual machine: 0:49 (0:38 + 0:11, a savings of 2:41)
• Cold-boot the 64-bit Windows 7 virtual machine: 1:37 (essentially no change)

Some notes:

• The Mac boots five seconds faster if it’s not connected to the Time Machine external drive on startup. The slower time is listed as it’s a more direct comparison.
• The Linux VM appears to boot far slower than it should, apparently due to the BTRFS file-system check. A plain-jane EXT4 install would probably boot much faster. This will likely continue until BTRFS reaches maturity, which may take a few more years.
• Once the Mac and Linux machines display the desktop, they seem completely usable now (unlike before installing the SSD — see the earlier entry for details), so the extra six and eleven seconds after that point shouldn’t really count as part of the boot process anymore. They’re listed here anyway for reasons of comparison.
• The Windows VM shows essentially no change, which is expected as it hasn’t been tweaked at all yet.

And the compile delays that started all this? There’s no way to tell for certain until it has gone through a week or two of normal use, but judging by what I’ve seen so far, they may be gone. 🙂

If the SSD lasts for a few years, this will be a near-perfect upgrade. It has certainly greatly reduced the hard drive bottleneck problem that this machine has had from the beginning, and maybe all but eliminated it. Time will tell, but I’m cautiously optimistic.

(Addendum: as an amusing coincidence, this article appeared on The Register as I was writing this entry.)

Solid State Drives. Ridiculously fast. Ridiculously expensive too. I’ve wanted to move to one for years, but one major thing held me back: their longevity. Not only do they fail, but according to both Jeff Atwood and Joel Spolsky (old-school computer geeks who I highly respect), they fail catastrophically, and in a really, really short time.

Jeff Atwood may be fine with that, but I’m not. If they were a lot less expensive (or I were making a lot more money), I could afford to keep a spare or two around all the time and just rely on my paranoid backup system to minimize down-time and data loss, but at present they’re way too costly for that.

On a system that could handle two drives, I’d do it in a heartbeat. Unlike most people, it would have a major impact on my work, because even with the extra memory I added earlier this year, my programming work hits a bottleneck with hard drive I/O on a multiple-times-a-day basis. A small and relatively cheap SSD with nothing but the operating systems and executable files on it, with a large conventional (i.e. magnetic spinning media) drive for my data and swap files, should all but eliminate that problem. With that setup and the right OS settings, the SSD is almost never written to, so presumably it would last a lot longer. I could even reduce the memory devoted to my Linux and Windows virtual machines if desired, since the main thing I need the free memory for is a large disk cache for compiling programs; if the compiler’s files were on an SSD, much of the need for that should vanish.

However, this MacBook Pro is a laptop, and for all its hardware greatness, it has only a single hard drive like almost all laptops. The size of SSD I’d need for all the data I need to carry around is prohibitively expensive at present. If I knew the drive would last I might be able to justify the cost, but knowing that it’s likely to die regularly if used as the only drive in the system, that option just isn’t open to me.

Except that it turns out that there is a way to put a second drive in this machine. 😀

There are two major contenders for this, the MCE OptiBay and the OWC Data Doubler. They both work the same, letting you replace the DVD drive in the machine with a second 2.5″ hard drive, and they’re both relatively inexpensive (I’ve heard that there are versions offered through eBay for ridiculously low prices, but I’d rather not have to do the quality control myself). I rarely need to use the DVD drive these days, so making that a little less convenient is an acceptable trade-off to me, in a way that using an external hard drive isn’t.

(The Data Doubler looks like it’s made of blue plastic, so I initially decided on the OptiBay. Unfortunately, for reasons I won’t go into here, it would have taken several weeks to get it. The Data Doubler was immediately available though, and it turns out that what looks in the pictures like plastic is actually aluminum, so I jumped on it. I was even able to get it for noticeably less than the OptiBay would have cost me.)

So, since the problem is no longer moot, what SSD to get? It’s still a pretty new technology, and both speed and reliability are increasing quickly. That said, there doesn’t seem to be a perfect one yet; they all have problems or limitations of one sort or another.

After a bit of research, the 180GB Intel 520 series won, based partly on this review and the user comments on it. The 120GB one would provide more storage than I’m likely to need, but it’s slower than the 180GB model; higher-capacity versions have the same speed as the 180GB one, so the price and speed put the 180GB one in the sweet spot. This MacBook Pro has SATA3 6Gb connections to the optical bay, so I should be able to get the maximum speed out of the SSD with it.

With both parts ordered and on their way, there’s nothing left to do but prepare the system for their arrival and wait impatiently.

Remember how I said that every SSD these days seems to have at least one problem or limitation? The one on that particular drive seems to be that it gets a severe and permanent drop in write-speed if the drive ever gets completely full. The review calls that a corner case, but there’s one place where it’s standard: full-disk encryption writes incompressible pseudo-random data to every sector of the disk. As it happens, this system has been using Apple’s FileVault, a full-disk encryption program. Not a good combination. Removing it was a six-hour operation, though the machine was completely usable the entire time.

Boot-time measurements aren’t really relevant to actually using the system (how often do people really have to reboot these days?), but they make a good proxy for the problem of disk I/O, so here are the measurements after turning off FileVault but before any other changes to the system:

• Cold-boot the Mac: 1:23 (1:03 + 0:20)
• Cold-boot the Linux virtual machine: 3:30 (2:43 + 0:47)
• Cold-boot the 64-bit Windows 7 virtual machine: 1:36

The numbers for the Mac and Linux machines are the total, then in parentheses, the time between hitting the start button (hardware or VM) and getting to the password screen, and the time between hitting Enter on a completed password and the drive stops reading constantly. This Windows VM is set to auto-login, so it doesn’t have a password screen.

The choice of drive-stops-reading-constantly as a stopping point, instead of when the OS’s desktop screen becomes visible, was deliberate. All three look like they’re available much sooner than that, but if you try to use them before the drive stops reading, you’re usually stuck tapping your fingers while they struggle and strain to load the first program.

Only Skype auto-starts on the Mac, only my instant-messaging program auto-starts on the Linux VM, and no user programs auto-start on the Windows VM. Nothing else was being done on the system while the VMs were booting.

One other item of note: before removing FileVault, the Mac boot times were much higher (2:21 from the password screen to drive-stops-reading-constantly, plus a few seconds before the password screen). The VMs weren’t noticeably affected by the change.

Other than that, there isn’t much to do until the parts arrive. The Linux VM is already set up with separate virtual hard drives for the OS and data; other than moving some log files and the tmp directory and turning on noatime on the system drive, there’s little else needed. The Windows VM can stay on the magnetic drive for now, and there’s not much that can be done about the Mac drive until the SSD appears. It’s all a waiting game now.

I’ll post more once the parts arrive, which should be on or before next Wednesday, barring disaster.