SSD Bad Block Tables and Memory Remapping Explained
Solid-state drives (SSDs) maintain data integrity and performance through internal management systems designed to handle physical hardware degradation. This article explains what a bad block table (BBT) is, how NAND flash memory cells fail to retain binary charges over time, and the step-by-step process the SSD controller uses to remap corrupted blocks to spare storage cells without data loss or user intervention.
NAND Flash and Binary Storage Basics
NAND flash memory stores digital information in a binary format—strings of 0s and 1s. This is accomplished by trapping electrical charges inside microscopic floating-gate or charge-trap transistors:
- Voltage States: Different charge levels within a cell represent distinct binary values (e.g., Single-Level Cell stores 1 bit, Multi-Level Cell stores 2 bits, Triple-Level Cell stores 3 bits, and Quad-Level Cell stores 4 bits).
- Physical Structure: Memory cells are organized into pages (typically 4 KB to 16 KB), and multiple pages form a block (typically 2 MB to 8 MB).
- Wear and Tear: Reading binary data is non-destructive, but writing (programming) and erasing requires pushing electrons through an insulating oxide layer. Over thousands of Program/Erase (P/E) cycles, this oxide layer degrades. When it breaks down, cells can no longer reliably hold a charge, causing binary bit flips and read/write failures.
What Is a Bad Block Table (BBT)?
A Bad Block Table (BBT) is an internal database maintained by the SSD controller’s Flash Translation Layer (FTL). It serves as a master registry of all physical blocks on the NAND flash chips that are unfit for reliable data storage.
There are two primary classifications of entries in a BBT:
- Factory Bad Blocks (Initial Bad Blocks): Defects that occur during the semiconductor manufacturing process. The manufacturer tests each chip, identifies non-functional blocks, and writes them into the BBT before the drive ships.
- Grown Bad Blocks (Runtime Bad Blocks): Blocks that were functional initially but degraded through regular usage, electrical stress, or component wear over the drive’s operational lifespan.
The BBT is stored in dedicated, redundant non-volatile areas of the NAND flash and loaded into high-speed controller RAM during drive startup for real-time reference.
How the SSD Detects Failed Cells
Before a block can be marked as bad, the SSD controller must identify that its binary data is at risk. This detection happens through several mechanisms:
- Error Correction Code (ECC) Thresholds: SSDs use advanced algorithms, such as Low-Density Parity-Check (LDPC), to detect and correct binary bit errors. When the number of corrupted bits in a block approaches the maximum limit that the ECC can correct, the controller flags the block.
- Program Failures: If a write operation fails to shift the cell voltage to the intended binary state within the allowed timeframe, a failure is reported.
- Erase Failures: If an erase command fails to reset the entire block back to its default erased binary state (all 1s), the block is flagged.
The Cell Remapping Process
When a block is identified as failing or unstable, the SSD controller executes a remapping procedure using its over-provisioned (spare) capacity:
[Host Request: LBA 1050]
│
▼
[Flash Translation Layer (FTL)]
│
├──► Checks Bad Block Table (BBT)
│
├─── Corrupted Block (PBA 402) ──► Retired & Added to BBT
│
└──► Remapped to Spare Pool ─────► Healthy Block (PBA 908)
- Data Reconstruction: If the data inside the degrading block can still be read or reconstructed via ECC and internal RAID-like parity (e.g., Rain/Die-RAID), the controller extracts the correct binary sequence.
- Allocation from Spare Pool: SSDs include extra storage capacity not visible to the user, known as over-provisioning. The controller selects a fresh, healthy physical block from this reserved pool.
- Writing to the New Block: The reconstructed binary data is written to the newly assigned physical block.
- Updating the Flash Translation Layer: The controller updates its internal mapping table, which links the operating system’s Logical Block Addressing (LBA) to the SSD’s Physical Block Addressing (PBA). The host operating system still requests the original LBA, but the SSD internally routes the request to the new PBA.
- Retiring the Bad Block: The failing physical block address is permanently marked as invalid in the Bad Block Table. The controller permanently excludes this block from future read, write, or erase cycles.
Preserving the Binary System
By decoupling logical addresses from physical locations and constantly referencing the Bad Block Table, SSDs guarantee that binary sequences remain intact despite physical hardware degradation. The operating system continues to read and write 0s and 1s to continuous logical addresses, while the SSD controller quietly isolates failing transistors beneath the surface.