Concepts at a Glance¶
What this page covers: UBI’s five key abstractions (PEB, LEB, EC, VID, EBA) and the six steps that describe its runtime behaviour. This is the shared vocabulary used throughout the rest of the documentation.
Prerequisites: What is UBI? for the high-level pitch.
After reading this: You will recognise every term used in the architecture, configuration, and API pages. For implementation depth, continue to Architecture Guide.
Five key concepts¶
Concept |
Abbreviation |
What it is |
|---|---|---|
Physical Erase Block |
PEB |
A hardware erase unit on the flash chip (e.g., 8 KB). The smallest unit that can be erased. |
Logical Erase Block |
LEB |
A virtual block exposed to the application through a volume. Maps to exactly one PEB at a time. |
Erase Counter |
EC |
A per-PEB counter tracking how many times that block has been erased. Used for wear-leveling decisions. |
Volume Identifier |
VID |
A header on each data PEB that links it to a specific volume and LEB number. |
Erase Block Association |
EBA |
The in-RAM mapping table from LEBs to PEBs. Rebuilt from VID headers during initialization. |
The fundamental relationship. An application writes to LEBs (logical). UBI maps each LEB to a PEB (physical), choosing the least-worn free block. The VID header on each PEB records which volume and LEB it belongs to. The EC header records how many times it has been erased.
How it works in six steps¶
1. Initialization — scan and rebuild¶
UBI scans every PEB on the flash partition, reads EC and VID headers, and rebuilds the in-RAM state: which PEBs are free, which belong to volumes, which are dirty (stale), and which are bad.
2. Free, dirty, and bad pools¶
After scanning, each PEB is classified into exactly one pool:
Pool |
Meaning |
|---|---|
Free |
Erased, ready for new writes. Stored in a red-black tree keyed by erase count. |
Mapped |
In use by a volume (tracked in that volume’s EBA table). |
Dirty |
Contains stale data from a previous write. Needs erasure before reuse. |
Bad |
Failed I/O. Permanently excluded. |
3. Writing — pick the least-worn PEB¶
When writing to a LEB, UBI selects the free PEB with the lowest erase counter (wear-leveling). It writes the EC header, VID header, and user data to the new PEB, then updates the EBA mapping. If the LEB was previously mapped, the old PEB moves to the dirty pool.
4. Reading — look up the EBA¶
Reading is a direct lookup: find the PEB mapped to the requested LEB in the EBA table, then read from the correct offset on flash.
5. Reclaiming — erase dirty PEBs¶
Dirty PEBs are reclaimed by erasing them, incrementing their erase
counter, writing a new EC header, and moving them back to the free pool.
The application controls when this happens by calling
ubi_device_erase_peb().
6. Recovery — sequence numbers resolve conflicts¶
If a power loss occurs mid-write, two PEBs may claim the same LEB. During
the next initialization, UBI compares their sequence numbers (sqnum in
the VID header) — the higher sqnum wins, and the loser is moved to
dirty.
What’s next¶
Quick Start — build, flash, write, read in 5 minutes.
Architecture Guide — on-flash layout, header formats, in-RAM structures, and operation flows in detail.
Configuration — Kconfig, devicetree, and memory sizing guide.