Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to measure the performance drop-off in solid state drives when the drives are getting close to full capacity. In particular, I would like to benchmark random and sequential read/writes.

Is this possible in IOmeter? How should I configure IOmeter to run a test like this?

share|improve this question
up vote 1 down vote accepted

Anandtech had a really, really great article on SSD's, benchmarking, and what they're good for. They used IOmeter to run their benchmarks, and gave some tips as to what kinds of problems they ran in to.

page 12 describes how they simulated a 'used' drive that has been hammered on a lot. They did this in order to benchmark how much performance would degrade over the life of the drive.

share|improve this answer
Thanks! I had read that article earlier, but didn't read that particular page in detail. I'll update this page with detailed instructions. – user4552 May 29 '09 at 18:37

Be prepared to do a lot of testing. I spent a great deal of time trying to understand the relationship between number of writes and write performance of the generally excellent FusionIO devices. The vendor wasn't too helpful in understanding the situation at first.

Remember that the definition of a "free" block can vary. For example, if you wrote to it ever, the storage can't consider it free. Perhaps if you later write to it with all 0's or all 1's, it can flag it as a free block although I have not seen this in practice. I found shocking performance artifacts by creating a logical volume that was only a small portion of the overall storage. Then, creating a logical volume that contained the rest of the storage, writing to it heavily for a half-hour, and deleting the logical volume. To the SSD, these blocks are of course not free. But I had forever destroyed the write performance by doing this test.

By formatting the device with extra "reserved" blocks, the reality of the performance impact was made irrelevant. The FusionIO devices support fast writes because they erase the reserved blocks in the background, and use them for new writes. (The block you overwrote is flagged as free, and later gets erased).

share|improve this answer
Good points, but it's worth mentioning that this very situation is what the ATA TRIM command will avoid - it'll allow the filesystem/OS to tell the SSD which blocks are actually free, and the SSD can then go through and delete them pre-emptively. – Daniel Lawson Jul 23 '09 at 22:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.