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.)