SSD Experiments

Intro

We're looking at SSDs for a few reasons

1. They can provide roughly 2-2.5x the read bandwidth (and sometimes nearly that much for writes, too) of disks.
2. They have much lower write latency (RAMCloud may be attractive without battery backups/Agigatech stuff/etc, if we use synchronous flash writes to get durability.
3. We don't need huge capacity, so the cost is reasonable (~$1.6/GB)

Controllers

There appear to be half a dozen different manufacturers of SSD controllers (Marvell, Intel, JMicron, Samsung, Indilinx, Toshiba, Sandforce).

Troublingly, some controllers or associated firmwares appear to be considerably less reliable than others (judging from consumer reviews on, e.g., NewEgg.com). E.g. the Indilinx and JMicron ones seem especially suspect. Sandforce-based drives also look a little sketchy depending on the vendor (perhaps they're making stupid firmware modifications?). Even Intel appears to ship buggy firmware!

Drives We're Evaluating

We looked at 4 drives with chips from Marvell, Intel, Samsung, and Toshiba:

(*) Guess based on various hardware review site tear-downs.

Read Performance: Random 8MB reads

This experiment targets recovery -- how quickly can we read 8MB segments from the disk?

The result is boring -- all disks can average between 260 and 270 MB/s (which is apparently about all we can expect of our 3Gbps SATA ports).

-TODO- 8MB latency may be interesting. If we have lots of nodes, we may only read a few segments. Hopefully that offers just as good bandwidth as reading a lot of them.

Write Performance: Random 8MB writes to some fraction of the disk

This experiment writes 8MB segments randomly to the first x% of the disk, for varying values of x. The total data written in each test is twice the drive's reported capacity.

The idea is to test how well write performance holds up under increased space utilisation. For example, if we write 120GB to the first 20% of the disk's logical blocks (randomly overwriting), how does the drive fare? We'd hope that when utilisation isn't too high, the drive's FTL would be able to efficiently erase recently overwritten LBAs and keep up with the write load.

Before each run, the disks were trimmed using hdparm. Perhaps a secure erase would have been better, but most drives appeared to regain full write performance this way. Notably, the Mushkin one did not (the 100% test was first, followed by 20,40,60%...).