Many SSD Benchmark Reviews Contain Flaws
blog.zorinaq.com
blog.zorinaq.com
For example they are the only ones who seem to benchmark SandForce-based SSDs (from OCZ, Crucial, ADATA, etc) correctly by taking care of defeating the transparent compression and deduplication features of this controller. They did that by patching IOMeter to use blocks of random bytes instead of constant bytes.
If you only test the pathological it isn't informative if your real workloads could benefit from compression and de-duplication.
However they only do this for tests run with IOMeter, because most other benchmarking tools are unable to write random data. Which brings me back to one of my points that many benchmarking tools are flawed in the sense they don't take into account potential deduplication.
The nice thing is that I can plug in my workload mix - 90% read, 10% writes, point it to all of my raw devices, and it will test all combinations of small random, large sequential I/Os, multiple queue depths, and give me CSV file outputs showing my I/O per second, MB per second, and latency for every data point.
You can also tell it the size of your storage array or disk cache, which it will add to Linux kernel cache, and pre-warm the cache with /dev/random. For example, if I'm testing on a server with 64GB of RAM and 8GB of storage cache, it will pre-warm a total of linux kernel cache + 8GB, so it might pre-warm 60-70GB of data before each data point to get accurate, repeatable results without the effects of cached reads/writes.
That's it. Once I have these 6 synthetic results, that gives me more and better information than 9 out of 10 benchmarking articles on the Net.
I usually don't need more complex synthetic benchmark results (eg. x% read / y% write). After that I simply test the real workload.