How SSD Wear Leveling Works

Wear leveling is the controller's strategy for distributing write operations evenly across all NAND blocks in an SSD. Every NAND block has a limited number of program/erase (P/E) cycles before its cells can no longer reliably store data. Without wear leveling, the blocks hosting frequently modified data (operating system swap files, database journals, temp files) would wear out while blocks holding static data (installed programs, archived documents) remain nearly unused.

Wear leveling prevents this uneven aging. When wear leveling fails and the drive locks out, professional SSD data recovery can read the NAND directly to bypass the controller's mapping tables.

Static vs Dynamic Wear Leveling

Dynamic wear leveling is simpler to implement but less effective. If a drive has 100 blocks and 50 are occupied by static data that never changes, dynamic wear leveling only distributes writes among the other 50 blocks. Those 50 blocks wear at twice the rate they would if all 100 were participating.

Static wear leveling solves this by moving cold data. If block 1 has been erased 500 times and block 50 has been erased 10 times because it holds an old archive, the controller will move the archive from block 50 to block 1 and redirect new writes to block 50. The archive data is untouched by this relocation; it is simply copied from one physical block to another.

Write Amplification and Its Effect on Endurance

NAND flash has an asymmetry: writes happen at the page level (4-16 KB), but erases happen at the block level (256-512 pages per block, or 1-4 MB). To write new data to a page within a block that already contains data, the controller must:

1. Read all valid pages from the target block into a buffer
2. Erase the entire block (setting all cells to 1)
3. Write back the valid pages plus the new data to a fresh block

This means a single 4 KB host write can trigger a 1 MB block rewrite internally. The ratio of actual NAND writes to host writes is the write amplification factor (WAF). A WAF of 1.0 is ideal (every byte written by the host results in exactly one byte written to NAND). In practice, WAF ranges from 1.1 for sequential workloads with TRIM enabled to 10+ for worst-case random write patterns on a full drive.

Write amplification directly affects endurance. A drive with a WAF of 3.0 consumes P/E cycles three times faster than the host's write volume would suggest. TRIM reduces WAF by informing the controller which pages are invalid, allowing the garbage collector to erase blocks without copying stale data.

How the Controller Tracks Block Wear Counts

The controller maintains a table mapping each physical block to its current P/E cycle count. This table is stored in the SSD's internal metadata area (part of the Flash Translation Layer data structures) and updated every time a block is erased.

The controller uses this table for wear leveling decisions. The algorithm varies by manufacturer: some use simple minimum-P/E-count selection, others use threshold-based triggers that initiate static wear leveling only when the difference between the most-worn and least-worn blocks exceeds a configurable delta.

If the controller's FTL crashes or the metadata area corrupts (common during power loss), the wear count table may be lost. In this scenario, the controller may fall back to conservative defaults or fail to initialize. Recovery tools like PC-3000 SSD can access the raw NAND data and rebuild FTL structures, but the granular wear count data may not be recoverable. This FTL corruption pattern is especially common on DRAM-less Silicon Motion controllers that rely on Host Memory Buffer.

Wear Leveling Count Carries Two Separate Numbers

A SATA drive does not publish the block wear table described above. It publishes a summary of it as a SMART attribute, and that attribute arrives as two distinct fields. smartctl prints them next to each other: a normalized value under the VALUE column, and a raw value under RAW_VALUE.

These are not two views of one quantity that can be checked against each other. The raw value is the counter the drive's own firmware keeps. The normalized value is what that firmware's arithmetic turns the counter into before reporting it. The smartmontools documentation says who does the converting: Each vendor uses their own algorithm to convert this "Raw" value to a "Normalized" value, and smartctl itself "does not carry out the conversion between 'Raw' and 'Normalized' values: this is done by the disk's firmware."

Only one of the two fields has defined semantics. The normalized value exists to be compared against the threshold the drive reports for that same attribute, and the attribute is considered failed once the normalized value drops to or below that threshold. So the number it should be read against is the drive's own threshold for that attribute, not a number from any other drive.

The raw field has no such contract. Per the same documentation, the conversion from a raw value to a quantity with physical units is not specified by the SMART standard, so a raw wear field carries whatever unit and whatever direction the firmware author chose. The raw counter sitting beside the normalized value is not a percentage of life consumed, and reading it as one produces a wrong answer. Reading a specific attribute on a specific drive is a separate job, and it is the one covered under SSD NAND wear failure.

Vendor Firmware Defines Both the Number and the Scale

SMART attribute numbering is vendor-specific. The two IDs named on this page for one concept, 177 and 173, are that problem in miniature: the same idea, more than one number, depending on whose firmware is answering.

The readable label is supplied by the tool, not by the drive. smartctl accepts a drive database of per-model presets and a vendor-attribute option that "Sets a vendor-specific raw value print FORMAT, an optional BYTEORDER and an optional NAME for Attribute ID". What comes off the wire is a numbered field and a pair of values. The name printed next to it is the tool's decoding of that number for that model.

Two consequences follow. A vendor-specific wear attribute decoded on one vendor's drive tells you nothing about the same ID on another vendor's drive. And a tool that has no preset for a given model prints the field it read without a vendor meaning attached to it.

NVMe Drives Report Wear Through a Spec-Defined Log Page

NVMe does not use the SATA vendor-attribute table at all. The NVM Express Base Specification defines a SMART / Health Information log page, and the endurance field inside it is Percentage Used. The specification defines the field itself, which is the part the SATA mechanism never had.

What the specification says that field contains is a vendor specific estimate of the percentage of NVM subsystem life used, based on actual usage and the manufacturer's prediction of NVM life. A value of 100 indicates the estimated endurance has been consumed, and the specification adds that this "may not indicate an NVM subsystem failure" and that the value is allowed to exceed 100. The specification also fixes how often it moves: the value is updated once per power-on hour while the controller is not in a sleep state.

Percentage Used counts upward as endurance is spent. A normalized SATA attribute is read against its own threshold and has failed once it reaches or drops below it. They are different quantities on different scales, so there is no conversion between them and no sense in which one is higher or lower than the other. A drive reporting a low Percentage Used and a drive reporting a low normalized wear attribute are saying opposite things about themselves.

Wear Indicators Do Not Compare Across Controller Families

Every step of the reporting path is the manufacturer's choice. The normalization algorithm is the vendor's own. The raw unit is unspecified. Even the NVMe field, whose name and update cadence are fixed by specification, is defined as an estimate measured against the manufacturer's prediction of NVM life. Setting two drives' numbers side by side compares two manufacturers' predictions, not two amounts of remaining life.

Write amplification widens the gap. As the earlier section describes, the same host writes land on NAND multiplied by a factor that depends on the controller, the workload, and how full the drive is. Two drives handed identical work can therefore have spent different amounts of their erase budget, and the numbers they report about it were scaled by different vendors on top of that.

A Healthy Wear Counter Does Not Mean a Readable Drive

A wear indicator reports program/erase budget the controller has spent. It is not a prediction of the date the drive stops working, and it is not evidence that the drive is currently readable.

A drive can lose its mapping table without having exhausted its NAND. That is the failure described further up this page: a metadata write interrupted by power loss leaves the firmware unable to decide which copy of the FTL is authoritative, and the drive comes back at zero capacity or refuses to enumerate. Nothing in that sequence requires a single worn-out block, and the wear attribute in such a drive, if it can be read at all, reports a budget that was never spent.

Read the counter for what it measures. It is a reasonable trigger for migrating data off a drive that still works. It is not a diagnostic for a drive that has already stopped answering, because that work begins at the controller over the drive's own SATA or NVMe interface, which is where PC-3000 SSD operates.

What Happens When NAND Cells Wear Out

As a block approaches its endurance limit, several measurable changes occur:

• Bit error rate increases. The ECC engine corrects more errors per page. The raw bit error rate (RBER) rises from manageable levels toward the uncorrectable bit error rate (UBER) threshold.
• Program/erase time increases. Worn cells require higher voltages and longer pulse durations to program and erase, slowing down write operations.
• Data retention decreases. Worn cells leak charge faster, reducing the time data can be stored without power. A new TLC cell may retain data for years; a cell near end-of-life may retain data for weeks.

When a block's error rate exceeds the ECC correction capability, the controller retires the block and allocates a spare from the over-provisioned pool. SMART attributes track the number of retired blocks. When the spare pool is exhausted, the drive enters a read-only mode (on well-designed controllers) or fails entirely. Drives that drop offline after the spare pool is exhausted require SSD data recovery at the controller level, because the OS can no longer mount the file system.

Read Disturb and Why Wear Leveling Does Not Balance It

Reads stress NAND too. To read one page, the controller applies an elevated pass-through voltage to the other word lines in the same block so those cells conduct no matter what they hold, and that pass-through voltage nudges charge in cells the read never targeted. The disturbance accumulates with every read of that block.

This is the wear vector the block-rotation model above does not account for. Wear leveling distributes program/erase cycles, so the controller's rotation logic counts erases and nothing else. A block holding cold data can sit at a low P/E count while the pages sharing it with a heavily read page drift toward the ECC correction budget.

Read disturb is not permanent damage to the cell. Erasing the block clears the accumulated charge, so controllers deal with accumulating read disturb by relocating the block's contents to a fresh block and erasing the original, not by adjusting P/E counts. The cost is additional internal writes on a drive the host never wrote to.

The end state looks like endurance wear even when the erase counts say otherwise: a rising raw bit error rate on a block whose P/E count reads healthy. SMART wear indicators track erases, which is why they can look unremarkable on a drive that has started returning uncorrectable sectors.

Soft-Decision LDPC and Read Retry

Modern TLC and QLC NAND relies on the controller's LDPC soft-decision engine rather than legacy BCH hard-decision codes. BCH reads each cell as a flat 1 or 0. LDPC assigns a log-likelihood ratio per bit, derived from the cell's measured charge probability, and iterates until the codeword resolves.

Building that probability map is what a read retry does:

1. The controller re-reads the same page at a shifted read reference voltage
2. It repeats the read at successively shifted voltages, recording where each cell's charge falls relative to each threshold
3. The LDPC decoder iterates over the resulting charge-probability map until the bit errors fall inside the correctable margin

Parity is computed last on the write path so that it protects the final stored state, which fixes the order on the read path: LDPC decodes the raw NAND data before anything downstream in the pipeline touches it. Nothing further along the read path sees a usable byte until that decode succeeds.

What escalating read retry looks like from the host

Retry costs time. A drive whose cells need several shifted-voltage passes per read gets slow before it gets unreadable, and that slowdown is the symptom most people notice first.

A drive in this state enumerates normally, reports its full capacity, and still hands back sectors its own controller can no longer correct.

That is a different condition from a dead controller or a corrupt FTL, and it is diagnosed differently: the drive is still talking, so the question is which LBA ranges decode and which do not. That work runs over the drive's own SATA or NVMe interface, which is where the lab workflow for a drive that still responds begins.

Retention Loss on a Drive That Sat Unpowered

Stored charge leaks. Electrons escape through the tunnel oxide over time and faster under heat, the cell's threshold voltage drifts downward, and once it falls below the read reference voltage the controller applies, the controller registers a bit error. How much drift a cell tolerates depends on how many voltage states are packed into its window.

Wear and shelf time compound. A drive already near its endurance limit that then sits in a drawer for a year accumulates errors on both counts, so it reads back worse than an equally old drive that stayed powered and in service.

As retention loss accumulates, the raw bit error rate exceeds the controller's ECC capability and the result is corrupted files or a volume that will not mount.

Recovery re-senses the drifted charge instead of accepting the first read: PC-3000 SSD sends vendor commands that alter the read reference voltage per word line and read the same page many times at slightly different voltages, building the charge-probability map the LDPC decoder needs. An offline NAND reader taking hard-decision dumps has no equivalent control over the die, which is one of the constraints on reading NAND off the board.

Frequently Asked Questions