Solid State Drives

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.


  1. Neat! I’ve often thought of doing this upgrade, especially since I have a desktop with I think an extra hard drive bay. (And an ESATA port too for external drives), but for me performance isn’t all that critical and its one more thing I’d have to spend money on.

    • Hmmm, I think I only have one internal hard-drive bay. 🙁 It’s a slimline desktop computer, a Gateway SX-2800-01. (Cheapest I could find for a core2quad at the time.)

      • Since it’s a desktop, you could get away with an external data drive.

        I wouldn’t want to attempt it with this notebook, the places I use it sometimes — like in the driver’s seat of the car while waiting for GoddessJ to finish shopping — make that inconvenient at best, and downright dangerous to the data at worst. But with a desktop, none of that applies.

        • Yeah, and I do have an ESATA drive dock that accepts both laptop and desktop size (forget what sizes those are) hard drives and hard-drive substitutes. Thanks for the feedback! Though I don’t really think an SSD is in my budget right now…

  2. Speaking of solid state storage, upgrading to a smaller (less likely to have flaky issues with bad blocks) and newer ROM with new fixes (and assumedly newer bugs) the beta cLK with bad block detection told me that I’d gone from about 4-5 bad blocks to over a dozen bad blocks.

    I assume my phone isn’t too long for this world if its internal memory (which doesn’t just get modified by flashing, but by ordinary app installation and usage both data and program.) If so, I really need to figure out either a way to have the money available for a new phone, or to hock my guitar in order to pay for it. (The latter is guaranteed to work, I have an american-made guitar that keeps most of its value used, can even goe up in value as a “vintage” instrument if it was among a good quality model year and its around long enough. Though I didn’t get it as an investment originally, I got it because it sounded nice.)

    • Also, the new Nexus is rumored to be from LG, and although the specs of the rumored device are nice (true-HD IPS screen, quad core SoAC), I hear their build quality is even worse than Samsung and they might price it at the original Nexus price rather than the discounted price the Galaxy Nexus is currently available at.

      Another possibility, if I have the funds, is to get an HTC One X – it has dropped a lot in price unlocked and its not too much more than a Galaxy Nexus. The drawback will be that if T-Mobile hasn’t yet rolled out refarmed 1900MHz 3g band support in my neighborhood, it will only have 2g until that happens. (Promised by the end of this year, and they’ve already started in several places such as the NYC area; should happen pretty fast as it involves no new towers.) One thing I don’t like about the One X though, and the rumored new LG Nexus device according to its FCC filing, is no removable battery. Samsung Galaxy Nexus has a removable battery. (Accompanied by Samsung’s poor fitting though so it makes it hollow and plasticy, but at least Samsung doesn’t do the software or software support on this one, as it’s a Google Nexus device. Too bad Google switched from HTC for Nexus devices. It’d be neat if they used their new Motorola branch to make them, Motorola has even tougher devices than HTC! Albeit very locked as far as hacking goes.)

Comments are closed.