Wear Leveling

Flash endurance is limited at the physical-cell level. Moving writes among blocks can avoid exhausting a small region while other usable blocks remain lightly worn; it does not increase the intrinsic endurance of each cell. Address mapping lets the host address stay the same when the physical location changes. [3]

Dynamic wear leveling favors less-worn free blocks for incoming writes. Blocks containing unchanging data remain occupied, so free-block selection alone cannot bring them into circulation. Static wear leveling additionally moves such cold data. Here cold means infrequently updated, not physically colder. [2]

Linux UBI provides a concrete raw-flash example: it moves data from a low-erase used physical eraseblock into a higher-erase free block. The former block can then be erased and reused. UBI documents bit-flip-triggered scrubbing separately, even though both operations use data-movement machinery. [5]

Reclamation, balancing and refresh answer different questions: is space reusable, where is wear accumulating, and does stored data need attention? UBI sits below UBIFS and still exposes flash erase semantics; its implementation is not a description of every managed SSD controller. [6] [5]

Static migration consumes internal writes. Jiao and colleagues show how relocation thresholds and workload skew affect the tradeoff between erase-count balance and write amplification in FTLSim simulations. Their study does not justify a universal recommendation to disable wear leveling on commercial drives. [4]

The 2025 extension by Jiao and Yang evaluates three static policies: OBP, DP and PWL. Its lifetime simulation replays eleven traces in a 256 GiB logical space, with 284 GiB physical capacity and an assumed 500-erase retirement threshold. This is a model setting, not a measured limit for all QLC NAND. [1]

Capacity variance changes the comparison: the simulated device may shrink its exported space toward the workload footprint. Section 5 assumes that the file system discards unneeded data and treats contiguous-address maintenance overhead as negligible. A proposed shrinking interface is not a firmware switch on an ordinary fixed-capacity SSD. [1]

Keep the write counters separate. The 2025 paper's figure 5 reports wear-leveling-induced overhead, excluding garbage-collection copies; it is not total device write amplification. [1]

Hesela's interpretation of the evidence: dividing a device's rated TBW by its logical capacity counts host full-drive writes. It does not directly measure a physical block's P/E endurance, because internal write amplification, spare capacity and uneven wear intervene. Do not treat the paper's figure 1 proxy as a measured cell-endurance curve. [1]

Placement must respect retention as well as wear. Macronix warns that moving persistent code into a block near its wear limit can be counterproductive. An average erase count cannot by itself establish that all blocks safely retain their contents. [3]

When assessing a device, ask what its counters count, which blocks share a balancing pool, and whether firmware exposes internal writes or only host writes. Compare erase-count spread and write amplification under a documented workload; neither metric alone establishes remaining service life.