Measuring Write Amplification

Now let's take a look at write amplification. This behaviour happens when, under particular circumstances, the SSD must write much more data to its storage than the operating system has supplied - hence 'amplification'. The level of amplification is very dependent on the usage pattern, and causes the flash memory to wear faster than might otherwise be expected. Write amplification is a consequence of how SSDs are arranged internally, and the way flash works. Before data can be stored, the memory must first be erased to put it back to an 'unused' state. The problem of amplification arises because the smallest area that can be erased is generally much larger than the smallest area that can be written.

The process works as follows. As new data is written to the disk, the controller looks for an unused block to store it in. With updates, the new data also goes to an unused block, and the original block is marked as spare. Eventually, when the unused blocks have almost run out, the disk must start erasing spare ones. But before it can do this, it must first move data from surrounding valid blocks to free up the larger 'erase block'. It is this moving of data, invisible to the host computer, that is responsible for write amplification and hence increased wear.

Random write patterns, such as database updates, tend to lead to particularly high write amplification; our sequential writes should give a very low value (just over 1.0). We can verify this by looking across a large number of test runs and comparing the change in wear levelling count with LBAs written.

After run 63:

ID# ATTRIBUTE_NAME          VALUE WORST THRESH TYPE      RAW_VALUE
  5 Reallocated_Sector_Ct   100   100   010    Pre-fail  0
  9 Power_On_Hours          099   099   000    Old_age   542
 12 Power_Cycle_Count       099   099   000    Old_age   158
177 Wear_Leveling_Count     098   098   000    Pre-fail  61
179 Used_Rsvd_Blk_Cnt_Tot   100   100   010    Pre-fail  0
181 Program_Fail_Cnt_Total  100   100   010    Old_age   0
182 Erase_Fail_Count_Total  100   100   010    Old_age   0
183 Runtime_Bad_Block       100   100   010    Pre-fail  0
187 Reported_Uncorrect      100   100   000    Old_age   0
190 Airflow_Temperature_Cel 065   060   000    Old_age   35
195 Hardware_ECC_Recovered  200   200   000    Old_age   0
199 UDMA_CRC_Error_Count    100   100   000    Old_age   0
235 Unknown_Attribute       099   099   000    Old_age   26
241 Total_LBAs_Written      099   099   000    Old_age   131308515644

After run 275:

ID# ATTRIBUTE_NAME          VALUE WORST THRESH TYPE      RAW_VALUE
  5 Reallocated_Sector_Ct   100   100   010    Pre-fail  0
  9 Power_On_Hours          099   099   000    Old_age   934
 12 Power_Cycle_Count       099   099   000    Old_age   158
177 Wear_Leveling_Count     095   095   000    Pre-fail  243
179 Used_Rsvd_Blk_Cnt_Tot   100   100   010    Pre-fail  0
181 Program_Fail_Cnt_Total  100   100   010    Old_age   0
182 Erase_Fail_Count_Total  100   100   010    Old_age   0
183 Runtime_Bad_Block       100   100   010    Pre-fail  0
187 Reported_Uncorrect      100   100   000    Old_age   0
190 Airflow_Temperature_Cel 067   060   000    Old_age   33
195 Hardware_ECC_Recovered  200   200   000    Old_age   0
199 UDMA_CRC_Error_Count    100   100   000    Old_age   0
235 Unknown_Attribute       099   099   000    Old_age   26
241 Total_LBAs_Written      099   099   000    Old_age   517663463195

First let's check that we have written what we would expect over this number of runs:

Data written by test = (275 - 63) * 869GiB / 1024 = 179.91TiB.

Data written to SSD = (517663463195-131308515644) * 512 / (1024 * 1024 * 1024 * 1024) = 179.91TiB.

So - we are only writing what we expect. But is the SSD amplifying this? The wear levelling count has gone up from 61 to 243: 182 extra cycles. Given that this is nominally a 1TB SSD, this is a very close match to the data written, and suggests that there is very little write amplification taking place. This confirms that writing sequentially is an extremely efficient way of using a SSD.

Later in the testing, we will see how write amplification is affected if there is a large file occupying half the capacity of the disk, which will stretch the controller as it conducts wear levelling. But for now - that's a great result!