SSD write amplification: measure WAF and reduce wear

An application reports 10 TB written, but the NAND inside its SSD may have absorbed much more. The difference is write amplification: internal data movement that the host did not request directly.

This does not mean the SSD is defective. NAND erase rules make some internal rewriting normal. The engineering question is whether the workload, capacity policy and controller keep that extra work within the endurance and latency budget.

WAF in one equation

Write amplification factor is commonly expressed as:

WAF = data written to NAND or media / data written by the host

If the host writes 100 GB and the device records 200 GB of media writes over the same interval, WAF is 2.0. NVM Express gives the same relationship: with WAF 2, a 4 KB host write ultimately produces 8 KB of media writes [1]. SNIA defines write amplification as device writes beyond those requested by the host [3].

WAF 1.0 is the theoretical no-extra-write case. A value below or above a particular threshold is not automatically good or bad without context. Compression, counter definitions, metadata, cache policy and sampling interval can change what the device reports.

Why an SSD rewrites data

NAND pages are programmed but whole erase blocks are reclaimed. When a block contains both valid and invalid pages, the controller may copy the valid pages elsewhere before erasing it. Those copies add media writes.

WAF tends to rise when:

• the SSD is nearly full and has fewer free blocks;
• the workload issues sustained small random updates;
• short-lived and long-lived data are mixed in the same erase blocks;
• writes are poorly aligned to the device's preferred boundaries;
• garbage collection repeatedly moves still-valid data;
• a write cache first stores data in one NAND mode and later folds it into another;
• host, filesystem, database and device each add their own metadata or copy-on-write behavior.

Higher WAF can reduce write throughput, increase latency and consume program/erase endurance. SNIA describes the connection between garbage-collection copies, WAF and usable SSD life [4].

WAF is not the same as filesystem write amplification. A database may turn one logical record update into several host writes before the SSD sees it; the SSD may then amplify those writes again. Measure each layer separately when optimizing a stack.

Measure deltas, not one screenshot

Many NVMe and SATA drives expose lifetime host-write counters. Media or NAND-write counters are less standardized and are often vendor-specific. A raw SMART attribute number without its unit is not evidence.

Use this workflow:

1. Confirm the exact model, capacity and firmware.
2. Obtain the vendor definition and unit for host writes and media/NAND writes.
3. Capture both raw counters at time A.
4. Run a representative workload long enough to include steady-state garbage collection.
5. Capture the same counters at time B.
6. Convert both deltas to the same byte unit.
7. Divide media-write delta by host-write delta.
8. Record fill level, free space, workload, temperature and power cycles with the result.

For example:

The interval WAF is 3.6 / 1.5 = 2.4.

Do not divide the device's lifetime media writes by an application counter that started last week. Do not combine decimal TB and binary TiB without conversion. Check whether counters reset after firmware update, sanitize or power events.

Micron warns that instantaneous WAF can vary significantly and recommends measuring over several days of typical workload in its client-SSD guidance [2]. A short empty-drive benchmark can miss the steady-state behavior that matters.

Read WAF with endurance ratings

TBW and DWPD describe the host-write workload allowed under the product's stated warranty and conditions; they do not promise that every workload produces the same internal wear. Our TBW and DWPD guide explains those ratings.

Suppose two applications each write 1 TB per day:

• Application A produces WAF 1.4, or roughly 1.4 TB of measured media writes.
• Application B produces WAF 4.0, or roughly 4 TB of measured media writes.

Their host traffic is equal, but the flash workload is not. This is why an SSD qualified with sequential transfers may age differently under a small-block database or virtual-machine workload.

Percentage Used and other health fields remain important, but do not reverse-engineer remaining days from WAF alone. Controller wear leveling, NAND endurance, spare blocks, error correction and vendor policy all contribute. Trend NVMe SMART health signals together.

Ways to reduce avoidable WAF

Change one variable at a time and remeasure.

Preserve working space

Leaving unallocated or otherwise controller-usable capacity can give garbage collection more choices. Micron notes that additional overprovisioning may improve performance and reduce wear for heavy, small-random-write workloads [2]. The right amount is workload-specific; capacity sacrificed without measurement may bring little benefit.

Send deallocate information

TRIM or NVMe Dataset Management deallocate tells the SSD which logical blocks no longer contain needed data. That can reduce how much invalid data the controller preserves during collection. Confirm the filesystem, OS, RAID or virtualization layer actually passes the information through.

Make writes easier to place

Batching tiny updates, aligning writes and separating hot short-lived data from cold long-lived data can reduce fragmentation. Modern host-directed interfaces such as NVMe Flexible Data Placement are explicitly designed to reduce WAF by improving data-placement cooperation [1], but they require support across the SSD and software stack.

Select for the real workload

Compare SSDs after identical preconditioning, fill level and workload duration. Require the exact controller, NAND and firmware or a requalification trigger. A product with more suitable overprovisioning, endurance class and firmware may outperform a higher headline-speed drive under sustained random writes.

If write speed starts high and then settles lower, first separate WAF from SLC cache exhaustion and from the effects of a nearly full SSD.

A practical acceptance record

For each qualified SSD and workload, retain:

• model, capacity, firmware and fixed-BOM identifiers;
• preconditioning and fill-state procedure;
• host and media counter definitions and raw snapshots;
• interval WAF, throughput and latency percentiles;
• temperature and throttling observations;
• Percentage Used and error-log baseline;
• capacity headroom, TRIM/deallocate and filesystem settings;
• pass limits and requalification conditions.

This turns “WAF seems high” into a repeatable comparison and protects the result from a silent firmware or component change.

Bottom line

Write amplification is the extra media writing created while an SSD manages NAND. Calculate it from documented host-write and media-write deltas over the same representative interval. Then test free space or overprovisioning, deallocate support, write shape and product choice one change at a time. Lower WAF can improve sustained behavior and preserve endurance, but only the exact drive and workload can establish the useful target.