Flash Translation Layer (FTL)

The Flash Translation Layer (src/opennandlab/ftl) is a critical component of OpenNANDLab v2.0.0, mapping logical addresses from the host to physical locations on the NAND flash device. This abstraction masks the complexities of NAND flash (such as erase-before-write requirements and wear leveling) from the host system.

Page-Level Mapping

OpenNANDLab defaults to a Page-Level FTL mapping strategy, providing the finest granularity and optimal random-write performance.

Logical-to-Physical (L2P) Translation

  • Flat Array Strategy: The L2P table is implemented as a highly efficient flat integer array (array.array('i')). This guarantees \(O(1)\) lookup times while maintaining a minimal memory footprint—providing a 4x memory usage reduction compared to dictionary-based mappings at scale.

  • Physical-to-Logical (P2L) Reverse Mapping: Maintained concurrently to facilitate efficient Garbage Collection (GC). When a block is selected for GC, the P2L table allows the FTL to instantly identify which logical page owns the physical data, allowing validation without exhaustive searches.

Data Structures & State Management

Physical Page States

Every physical page in the simulated device is tracked using a tightly packed state mechanism:

  • FREE: The page is erased and ready to be written.

  • VALID: The page contains current, active data.

  • INVALID: The page contains obsolete data (a new version was written elsewhere).

Write Buffering

To maximize performance and interface efficiency:

  • Writes from the host are intercepted by a localized Write Buffer (defaulting to 64 pages).

  • Compressed and scrambled data is held until the buffer fills.

  • Buffer flushes are sequential, ensuring data writes linearly across the NAND blocks, mirroring real-world controller behavior.

Free Block Pooling

The FTL allocates writes efficiently by utilizing a pool of available blocks:

  • Erased blocks are held in a deque (Free Block Pool).

  • The FTL maintains a single active_block.

  • Writes fill the active_block sequentially. Once full, the next block is pulled from the pool.

Garbage Collection (GC)

Garbage collection is the process of reclaiming INVALID pages to ensure a steady supply of FREE blocks.

OpenNANDLab integrates two primary GC policies:

1. Greedy GC

  • Mechanism: Selects the block with the highest count of INVALID pages.

  • Advantages: Provides the lowest immediate write amplification overhead during the GC cycle, as it requires moving the absolute minimum number of VALID pages.

  • Trade-off: May ignore “cold” data blocks for extended periods.

2. Cost-Benefit GC

  • Mechanism: Weighs the number of invalid pages against the age (or erase count) of the block.

  • Advantages: Dynamically prevents blocks from remaining stagnant. It effectively curates a mix of hot and cold data turnover, actively aiding the wear-leveling engine.

GC Triggers

  • Foreground GC: Triggers synchronously when the free pool drops below a critical threshold (e.g., 10% of total capacity) during a buffer flush.

Metrics & Telemetry

The FTL calculates the Write Amplification Factor (WAF) directly:

  • Host Writes: Tracked incrementally every time the host issues a write command.

  • NAND Writes: Tracked every time data is physically flushed, including internal copying during GC.

  • Formula: NAND Writes / Host Writes.

Extending the FTL

Developers can add new GC algorithms by subclassing the base GC structures within src/opennandlab/ftl/gc.py or completely alter the mapping strategy (e.g., Block-level or Hybrid FTLs) by replacing the PageFTL module while adhering to the core FTL API expected by NANDController.