SSD Power‑Loss Recovery: Normal vs. Abnormal Scenarios and Mapping Table Rebuild

SSD power loss can be classified into two categories: normal power loss, where the host notifies the SSD before power is removed, and abnormal power loss, which occurs without prior notification.

In a normal power‑down, the host sends a command such as SATA's

IdleImmediately

. Upon receiving this command, the SSD performs several actions before the power is cut:

Flush buffered user data from its internal buffer to flash memory.

Write the mapping table (logical‑to‑physical address map) to flash.

Record block information, including which blocks are written, their locations, and which blocks are invalid.

Store other SSD state information to flash.

After completing these steps, the SSD can safely lose power without data loss; on power‑up it simply reloads the saved state and resumes operation.

Abnormal power loss occurs when the SSD is powered off without receiving the notification or before it can finish the above steps. This can cause data loss in two ways: buffered user data may not reach flash, and if a write to an MLC flash’s upper page is interrupted, the corresponding lower page can become corrupted, potentially destroying previously stored data.

SSDs rely on volatile RAM (SRAM or DRAM) to cache user data and store the mapping table. When power is lost, the contents of this RAM disappear, which is why abnormal power loss is problematic.

To mitigate this, many enterprise SSDs include a capacitor that detects imminent power loss, discharges, and quickly flushes RAM contents to flash. However, capacitors cannot guarantee that all information is written before power disappears, so an additional recovery mechanism is still required.

Some designs explore replacing volatile RAM with non‑volatile alternatives that approach RAM’s performance, such as Intel‑Micron 3D XPoint, which combines the non‑volatility of flash with near‑RAM speed.

When the mapping table is lost, the SSD cannot translate logical addresses to physical locations, making data retrieval impossible. Fortunately, the mapping table can be reconstructed because SSDs embed metadata with each user data block. This metadata records the logical address, a timestamp, and other relevant information.

Reconstruction typically involves scanning the entire flash space to collect all metadata and rebuild the logical‑to‑physical map. While conceptually simple, a full‑flash scan is slow, especially for modern terabyte‑scale SSDs, where scanning can take minutes or longer.

To accelerate recovery, SSDs employ a checkpoint (snapshot) mechanism: periodically, the SSD writes the contents of its RAM—including the mapping table, cached user data, and status information—to flash, similar to the actions performed during normal power‑down. The latest checkpoint can be loaded on power‑up, and only the region of flash written after that checkpoint needs to be scanned, dramatically reducing reconstruction time.

Below are illustrative diagrams of metadata, storage layout, and the checkpoint process.