hesela.devBad block table
A bad block table records the usability status of NAND eraseblocks so a storage stack can avoid known unusable blocks.
Factory markers and a BBT are distinct metadata. Factory information can be lost during erase; preserve it using the device's documented procedure. [2]
The Linux v6.16 raw-NAND BBT implementation constructs an in-memory BBT from markers or a configured flash-resident table. Mirrored, versioned copies are optional. Its memory encoding distinguishes good, worn (a state label, not a cause diagnosis), factory-bad and reserved blocks; reserved table storage is not evidence of a physical defect. [1]
A status table is neither a complete logical-to-physical translation map nor data recovery for unreadable bytes. This distinction follows from its metadata role, not a hardware experiment.
Relations
- related
- Bad block management, NAND erase block, NAND spare area, Memory Technology Device (MTD), Flash translation layer (FTL)
Limitations
- Marker locations, encodings and persistence policies are device- and stack-specific; the Linux example does not describe every SSD. [1, 2]
Citations
- Linux v6.16, nand_bbt.c: table scanning, mirrored copies and reserved blocks
- Microchip. Bad Block Management, section 5.1: factory information and erase operations
Sources & caveats
- Source review of Linux v6.16 raw-NAND code and Microchip guidance. No device was erased or tested. Optional mirroring is not asserted to guarantee crash-atomic updates.