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:

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:

  1. 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.
  2. 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:

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)
  1. 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.
  2. 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.
  3. Writing to the New Block: The reconstructed binary data is written to the newly assigned physical block.
  4. 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.
  5. 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.