The most excellent Joe Landman has a blog post looking at the performance of an anonymous SSD with a Sandforce SF-1200 controller chipset on it, and comes up with some very interesting benchmark results. But first he comes up with a nice way of quantifying the distance between benchmark results and real life:

I need to understand how close the marketing numbers are to the actual numbers. We need to establish a ratio for this. Call this the Benchmark Significance Ratio, or BS Ratio for short. Define BS Ratio as:

BS Ratio = (what they claim) / (what you measure)

A BS Ratio close to 1 is good. A BS Ratio much greater than 1 is bad. Of course, a BS Ratio much less than 1 is either an indicator of a failed test, or an accidentally released product.

What Joe finds is that the performance of the SSD, in terms of basic things like read/write speed, depends on what you write to it. If you write lots of zeros you find the performance is almost 4 times as much as if you write random data to it. Now as Joe rightly points out, this smacks of compression somewhere in the path between the program and the disk which means that most of the benchmarks you see/do (unless they/you, as Joe does, take care to use random data) will be pretty much meaningless unless you plan to just store zeros. Mind you if you do plan to just store zeros then I suggest just using /dev/null for writing to and /dev/zero to read from – they will give you much better speed and far better capacity for free! 🙂

What intrigues me though is not so much the speed difference but what that means for the capacity of the device – does it claim to be a X GB device but actually store Y GB (where Y > X dependent on compressibility of data) or does it enforce the amount that it can store to the quoted capacity ? Even worse, does the stated X GB capacity depend on your data being compressible and more random data results in less space ? I think the last can be ruled out because I can’t see a way how you would fake that failure to the SATA layers unless you returned failed writes which could cause chaos, especially in a RAID environment. I also suspect that it must enforce a fixed limit as I presume they must fake some characteristics of a spinning disk (heads, etc) for compatibility.

Which is a real shame because you’ve actually got a storage device that could (given the right sort of data) store far more than its stated capacity, if only you could address it in a non-spinning disk like manner. This echo’s other issues with SSD FTL’s like bad wear levelling implementations, etc, which would go away if we had an open interface into the device exposing the internals, that way you could (with this controller) get extra storage for free and potentially even a better wear levelling system into the bargain.

I guess even if that were available I don’t know if filesystems could cope with that (yet), but I wouldn’t mind betting they’d be up for it!