| 1 | # Get a decent idea about the steady state performance of an SSD. |
| 2 | # |
| 3 | # First we sequentially write the drive. Then we completely |
| 4 | # overwrite the device again, this time randomly at 4K. The former gives |
| 5 | # us a good idea of the ideal write performance, you should see flat graph |
| 6 | # of steady write performance. The latter we would expect to start out at |
| 7 | # approximately the same rate as the sequential fill, but at some point |
| 8 | # hit a write cliff and hit steady state. The latency numbers of the steady |
| 9 | # state also provide a good idea of what kind of latencies to expect when |
| 10 | # the device is pushed to steady state instead of peak benchmark-like |
| 11 | # numbers that are usually reported. |
| 12 | # |
| 13 | # Note that this is a DESTRUCTIVE test. It operates on the device itself. |
| 14 | # It's not destructive in the sense that it will ruin the device, but |
| 15 | # whatever data you have on there will be gone. |
| 16 | # |
| 17 | [global] |
| 18 | ioengine=libaio |
| 19 | direct=1 |
| 20 | group_reporting |
| 21 | filename=/dev/fioa |
| 22 | |
| 23 | [sequential-fill] |
| 24 | description=Sequential fill phase |
| 25 | rw=write |
| 26 | iodepth=16 |
| 27 | bs=1M |
| 28 | |
| 29 | [random-write-steady] |
| 30 | stonewall |
| 31 | description=Random write steady state phase |
| 32 | rw=randwrite |
| 33 | bs=4K |
| 34 | iodepth=32 |
| 35 | numjobs=4 |
| 36 | write_bw_log=fioa-steady-state |