Some thoughts on my utter failure to configure a working dual-drive system.
Background: spinning rust is slow and prone to failure and SSDs are
fast and…well, I don't know about their long-term reliability but they're fast, ok?
I've long wanted to replace my conventional disk with an SSD, but 500Gb SSDs are still
out of my price range. In the course of a periodic check on just how out of range they
are, I came across the
data doubler,
a bracket that allows you to mount a SATA drive where the optical bay is.
I hatched a cunning plan. I'd pull out the optical bay and use the data doubler
to put in a second hard drive, an SSD in the affordable range. I'd boot off the SSD,
but leave most of my data on the conventional drive. My thinking was that having swap
and /tmp and such on the SSD would provide
a performance boost. And because I'd only be using it to boot, it could be small.
I selected a 120Gb SSD and charged ahead. After making a complete backup. Because
I may be crazy but I'm not (usually) stupid. At least, I try not to make the same
mistakes more than once.
The hardware was easy; the physical installation was quick and painless.
The software …; ah, software, thou art a heartless bastard. It all goes downhill
from here.
I should explain that there's one extra complication involved. I use
PGP Whole Disk Encryption (now a
Symantec product).
Laptops get lost and stolen. Governments sometimes decide to confiscate them at
borders. None of these things have happened to me, but if any of them do, I don't want
the added worry that I've let any confidential information on my laptop leak into
other hands. I don't consider myself paranoid, but then I suppose I wouldn't.
Problem one: the Snow Leopard
install DVD won't boot. After wasting time trying to determine if this was a consequence
of the external optical drive enclosure, I came to the conclusion that it's either
because of an EFI update
that's been done, or maybe the SSD needs drivers that aren't on the original DVD.
I dunno.
Boot the DVD on my old laptop, install onto a small USB, boot off the USB,
run “Software Update” several times, move that drive to my new laptop, boot off of it,
use
SuperDuper!
to install it on the SSD, and reboot with fingers crossed. Success.
Get the encryption software installed, (re)encrypt the drive(s), reboot.
Problem two: the second drive doesn't mount at boot time. Maybe this is
a consequence of the encryption. Maybe it's a consequence of the OS X auto mounter,
I'm not really sure. It means there's no practical way to simply put my home directory
on the spinning rust.
I looked around in the OS X boot sequence. Unlike Linux, it's
clearly not something mortals are supposed to tinker with. The
/etc/fstab says, literally, “IGNORE THIS FILE”.
There's no equivalent of
/etc/init.d AFAICT. There's
launchd and maybe the answer's in there, but I pressed
on with other techniques instead. More fool I, perhaps.
Mac OS X doesn't support the “bind” mount option. And
I couldn't see a practical way to make “union” mounts do what I wanted. What's more,
there's nothing like Linux's “Ctrl+Alt+F1” access to a console, so there are few
options for getting in between boot and graphical login.
(Logging in, luckily, does mount the second drive with an appropriate
passphrase prompt from the PGP software.)
Next I ran afoul of the Mac's aggressive defaulting of the
directory structure. Programs think ~/Documents is where documents go,
~/Pictures is where pictures
go, etc., and they think can put any amount of data in ~/Library/Application Support. Some programs
can be persuaded otherwise, but I've learned it's simpler to leave things
that way. But I don't want arbitrary amounts of data on my little SSD;
I quickly wound up with an ugly little rat's nest of symbolic links.
The problem with symbolic links (despite their enormous utility) is that
they're too visible. They're a trick of the filesystem and if you walk past
a symbolic link, or if an application knows its location by another name,
then relative paths aren't what you expect.
Finally, there's /usr/local.
There's a whole bunch of stuff in there that, again, I don't need on my
SSD. So I made that a symbolic link. Some library/linking issues persuaded
me to rebuild my Homebrew
install. Some aspect of that process persuaded me that the brew system needed
to know the real location (/Volumes/Data/usr/local).
That lead to the relative path problem aluded to above, solved with another symbolic
link (/Volumes/Data/Volumes→/Volumes).
You can see now that I've missed the
left turn in
Albequerque, can't you?
The final straw was the DisplayLink driver for my
(second, external) USB monitor. It put a library in
/usr/local. Which, now that
it's a symbolic link to a directory on an encrypted drive, isn't
available at boot time. It was sort of ok, as long as I didn't reboot
with the external monitor plugged in and logged in before I did plug
it in.
At this point, I gave up. The path I'd taken, the decisions I'd
made, left me with a sometimes bootable rat's nest. I'd clearly gone
so far off the reservation that it was only a matter of time before I
discovered something awful. At the least convenient moment.
Last night I restored from the backup and went back to booting
off the spinning rust. Four days lost, none the worse for wear, and perhaps
a little wiser.
On reflection, I think 120Gb probably should be enough
to install the OS and applications. I think I might try again, when I have
a chance, with only the absolutely necessary symbolic links (I'm thinking of
~/Library/Application Support/MarkLogic
and
~/Library/Application Support/Steam
in particular (though I know enough about MarkLogic to actually move the data
out of “application support” if I want.
I'll leave ~/Documents
and friends alone, chosing to put my data elsewhere on an
application-by-application basis. I'll leave /usr/local on the SSD, etc.
Maybe that'll work.
Performance metrics
Along the way, I took a few simple performance measurements.
Nothing terribly scientific, I didn't run several tests and average them, I didn't
work hard to make the conditions exactly the same, etc. One of the ways that I expected
an SSD to be an improvement was in the time it takes to build
Marklogic
Server. As a test, I timed the build. In each case, I ran the test on a freshly
booted machine with the same few apps running (stuff that starts when I login).
I ran make clean then timed the build.
Entirely on spinning rust, it took about 44 minutes of wall-clock time as reported
by time.
Booting off the SSD, but with the source files on spinning rust, it took
about 39 minutes.
Booting off the SSD, with the source files on the SSD, it took about 36 minutes.
So that's a maximum possible savings of just under 20%. Pretty good really,
though perhaps an awful lot of fuss for eight minutes. None of these tests took into
account the situation where I think the savings would be even more dramatic: when
there's enough going on to cause some swapping to occur. Running a build when I've
got another server, two Emacsen, a browser, some office app, and a
WebEx up, for example.
[And you need to do that how often? —ed]
![[L]](/graphics/linkgroup.gif)
