SEF Reference Flash Translation Layer (FTL)

The Software-Enabled Flash™️ (SEF) Reference FTL implements an asynchronous user mode block API using the SEF Library. The implementation serves as an example of how to use the SEF Library and demonstrates the following:

Managing a Flash Translation Layer (FTL) with multiple placement IDs
Persisting and recovering FTL metadata
Background garbage collection using I/O priority control
Handling and accounting for device wear

The code is implemented with simplicity in mind. Parts of the Reference FTL can be used in other projects or expanded and enhanced based on project requirements and needs.

The SEF Reference FTL is implemented as a shared library. The public, C-11 API is defined in sef-block-module.h. It implements an asynchronous block API using a host-based flash translation layer (FTL). Garbage collection is handled by the Reference FTL and supports a QoS Domain configured with multiple placement IDs. Over-provisioning is set with a one-time configuration of a fresh QoS Domain by calling SEFBlockConfig. Once configured, a context for a QoS Domain is obtained by calling SEFBlockInit. The returned context is required when issuing I/O with SEFBlockIO.

I/O is only asynchronous and inherits the threading model of the SEF Library. The FTL is designed to have no locking for reads, and, given adequate over-provisioning, limited locking for writes. Reads are never queued, and writes are only queued by the FTL when there are no available Super Blocks in the QoS Domain. The writes are queued until GC can recover a free Super Block. Garbage collection runs when the end of the over-provisioning is encountered. Blocked writes waiting for GC can be canceled by calling SEFBlockCancel.

The FTL’s LBA-to-flash address lookup table (LUT) is kept entirely in RAM. It is loaded in SEFBlockInit and saved in SEFBlockCleanup. In the case of a client/system crash, the saved LUT will be out of date but marked as dirty. When this happens, SEFBlockInit will fail. The LUT can be both checked and repaired by calling SEFBlockCheck. The current implementation rebuilds the LUT entirely from Super Block metadata, but the internal function that does the work is capable of updating a stale LUT by only processing the metadata of Super Blocks written after the LUT was last saved.

The SDK is made up of 7 components:

These sections document the internals and theory of operation for each layer.