The real world performance of a Flash device is shown when the Steady State is reached. In most cases these are not the performance values which are shown on the vendors website.
The SNIA organization defined a specification how to test flash devices or Solid State Storage. The industry would like to have a methodology to compare NAND Flash devices with a scientific approach. The reason why there is a need for this specification is that the NAND Flash devices write performance heavily depends on the write history of the device. There are three write phases of a NAND Flash device:
- FOB (Fresh- Out of the Box)
- Steady State
FOB (Fresh- Out of the Box) or Secure Erase(Sanitize?)
A device taken fresh out of the box should provide the best possible write performance for a while. Why? A flash device writes data in 4 KB pages inside of 256 KB blocks. To add additional pages to a partially filled block, the solid-state drive must erase the entire block before writing data back to it.
If the flash device fills up, fewer and fewer empty blocks are available. In their place are partially filled blocks. The NAND Flash device can’t just write the new data to these partially filled blocks — that would erase the existing data. Instead of a simple write operation, the NAND Flash device has to read the value of the block into its cache, modify the value with the new data, and then write it back. (Write Amplification)
Often when you would like to test a device some data has already been written to it. This means you can’t test the FOB performance anymore. For this it is possible to “Secure Erase” the device. This feature was original introduced to delete all data on a flash device securely which means that all pages/blocks will be zeroed even the blocks which are over-provisioned (not visible to the OS). But it can also be used to optimize the performance and restore the FOB performance for a while. The vendors provide tools for this. Be careful. Some vendors make us of Sanitize and Secure Erase as features. But the implementation is different. So a Secure Erase may only delete the mapping table and not the blocks them self.
The transition is the phase between the good performance of FOB and Steady State. Most of the time the performance drops continuously over time and the write cliff appears till the Steady State is reached.
The scientific definition for Steady State is:
A device is said to be in Steady State when, for the dependent variable
(y) being tracked:
a) Range(y) is less than 20% of Ave(y): Max(y)-Min(y) within the Measurement Window
is no more than 20% of the Ave(y) within the Measurement Window; and
b) Slope(y) is less than 10%: Max(y)-Min(y), where Max(y) and Min(y) are the maximum
and minimum values on the best linear curve fit of the y-values within the
Measurement Window,is within 10% of Ave(y) value within the Measurement Window.
Basically this means: Use a predefined write/read pattern and run this against the device until the performance of the device will be stable over time.
But should you run the test yourself? First a little bit math:
For (R/W Mix % = 100/0, 95/5, 65/35, 50/50, 35/65, 5/95, 0/100)
For (Block Size = 1024KiB, 128KiB, 64KiB, 32KiB, 16KiB, 8KiB, 4KiB,0.5KiB)
- Execute random IO, per (R/W Mix %, Block Size), for 1 minute
- Record Ave IOPS(R/W Mix%, Block Size)
The whole block will be run up to 25 times depending if Steady State is already reached. Each run will be for 1 Minute.
25 (maximum runs) * 7 (R/W mixes) * 8 (block sizes) = 1400 minutes = 23,3h
The test could run for ~24h and it will write a lot. I strongly advice that you don´t run the tests yourself as long as you agree that the device looses lifetime.
There are some scripts and tools which can be useful to test the device which are based on “fio”.
- a bash script by James Bowen. This scripts run for ~24 hours and does not stop even Steady State is reached
- tkperf by Georg Schönberger which I prefer
- block-storage git project by Jason Read which is aimed for cloud environments. A full implementation of PTS can’t be done in cloud environments. (For example: Secure Erase)
Using TKperf with SanDisk PX600-1000
TKperf is a python script which implements the full SNIA PTS specification. With Ubuntu its really easy to install.
After tkperf is installed and all dependencies as well I started a test. I tested a SanDisk PX600-1000 installed in Testverse. Because for the PX600 PCIe device you can’t run “hdparm” to Secure Erase, Georg Schöneberger implemented a new option “-i fusion” which leverages the SanDisk Command-line tools to Secure Erase the device. Again: Thank you @devtux_at
The following command runs all four SNIA PTS tests (IOPS,Latency,Throughput,Write Saturation). I ran with 4 jobs, an iodepth of 16 and used refill buffers to avoid compression of the device. The file test.dsc is a simple text file which describes the drive because “hdparm” can’t get infos about the PX600.
REMEMBER: ALL data will be lost and your device looses lifetime or maybe destroyed!
sudo tkperf -i fusion ssd PX600-1000 /dev/fioa -nj 4 -iod 16 -rfb -dsc test.dsc
tkperf generates some nice png files which summarizes the testing. And the tests reached steady state after 4-5 rounds.
The device was formatted with 512 bytes sector size. This was needed to run all tests. It would improve the performance for all bigger block sizes to format the device with 4k sector size!
This is the reason why these cards are that nice. Providing < 0,2 ms latency is great!