Replacing ALL disk with SSD?

I love Solid State Disks and have written about them extensively:

And, being a lover of SSD, I know they are a win in many situations including power savings. However, try as I might (and I have tried hard), I can’t find a way to justify using SSDs on power savings alone. In When SSDs Make Sense in Server Applications I walked through where flash SSDs are a clear win. They are great for replacing disks in VERY high IOPS workloads. They are great for workloads that can’t go do disk and must entirely be held by main-memory caches. In this usage mode, SSDs can allow the data that was previously had to be memory resident to be moved to SSD. This can be a huge win in that memory is very power intensive and, as much as memory prices have fallen, it’s still expensive relative to disk and flash.

In this recently released article, MySpace Replaces all Server Hard Disks with Flash Drives, it was announced that MySpace has completely stopped using hard disks. The article said “MySpace said the solid state storage uses less than 1% of the power and cooling costs that their previous hard drive-based server infrastructure had and that they were able to remove all of their server racks because the ioDrives are embedded directly into even its smallest servers.” Presumably they meant “remove all of the storage racks” rather than “remove all the server racks.”

I totally believe that MySpace can and should move some content that currently must live in memory and shift it out to SSDs and I like the savings that will come from doing this. No debate. I fully expect MySpace have some workloads that drive incredibly high IOPS rates and these can be replaced by SSDs. But in every company I’ve ever worked or visited, the vast majority of the persistent disk resident data is cold. Security and audit logs, backups, boot disks, archival copies, debugging information, rarely accessed large objects. Putting cold data without extremely aggressive access time SLAs on flash just doesn’t make sense. These data are capacity bound rather than IOPS bound and flash is an expensive way to get capacity.

The argument made in the article is that power savings of flash over SSD justify the cost per GB delta. I can’t make that math even get close to working. In Annual Fully Burdened Cost of Power we looked at the cost of fully provisioned power and found that if we include power distribution costs, cooling costs, and power, power costs $2.12 per watt per year. Given that a commodity disk (where cold data belongs) consumes 6 to 10w disk each and can store well over a TB, this math simply can’t be made to work. I have come across folks that think the power savings justify the technology change even for cold data but I’ve never seen a case where the assertion stood the test of scrutiny.

SSDs are wonderful for many applications and I would certainly replace some disks with SSDs but replacing ALL disks doesn’t make sense in the workload mixes found in most data centers. In this case, I suspect it was a communication error and MySpace has not really replaced all of their disk with SSDs.

Thanks to Tom Klienpeter who sent this one my way.


James Hamilton



b: /

2 comments on “Replacing ALL disk with SSD?
  1. I think you’re probably right Jeff. And, by the way, its great hearing from you. Its been a while.

    I 100% agree that Fusion I/O can deliver insanely high IOPS rates but, the price performance of the Intel and Samsung SSDs look a lot more attractive to me.


  2. Jeff Darcy says:

    I think the key is the "server" part of "server hard disks" – as in, they have some other "non-server" (i.e. external-array) hard disks that remain in place. Also, Fusion drives seem like expensive overkill for putting inside most servers. Sure, in the dedicated cache servers it might make sense, but the other kinds of servers would probably do fine with cheaper any-vendor SATA SSDs.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.