UBI Headers

UBI stores 2 small 64-byte headers at the beginning of each non-bad physical eraseblock:

• erase counter header (or EC header) which contains the erase counter of the physical eraseblock (PEB) plus some other not so important information;
• volume identifier header (or VID header) which stores volume ID and logical eraseblock (LEB) number this PEB belongs to (plus some other not so important information).

UBI 在每一个好的物理擦除块开始的位置保存两个64字节的头信息：

•  擦除计数头(EC header) - 记录 PEB 的擦除计数和其它没那么的信息
•  卷ID头(VID header) - 存储卷 ID ，本PEB所属的 LEB 号及其它信息

This is why logical eraseblocks are smaller than physical eraseblock - the headers take some flash space.

All UBI headers are protected by the CRC-32 checksum. Please, refer the drivers/mtd/ubi/ubi-media.h file in the linux kernel for more information about the header's contents.

When UBI attaches an MTD device, it has to scan it, read all headers, check the CRC-32 checksums, and store erase counters and the logical-to-physical eraseblock mapping information in RAM. Please, refer this section for information about scalability issues related to this.

LEB 比 PEB 小就是因为这些头部信息占了部分flash存储空间。

所有的UBI头都使用 CRC32 保护， 关于这些头信息， 要了解更多请参看 Linux 内核中的 drivers/mtd/ubi/ubi-media.h

当UBI attach 到一个 MTD 设备时， 它必须扫描设备， 读取所有的头信息， 校验 CRC-32,  把PEB的擦除计数和 LEB与PEB的映射信息存储到RAM。关于扩展性问题， 请参见 Scalability Issues 一节。 

After UBI has erased a PEB, it writes the EC header with increased erase counter value. This means that PEBs always have the EC header, except for the short period of time after the erasure and before the EC header is written. Should an unclean reboot happen during this short period of time, the EC header is lost or becomes corrupted. In this case UBI writes new EC header with an average erase counter just after the MTD device scanning is done.

当 UBI 擦除PEB之后， 它会增加 EC header的擦除计数信息； 这意味着 PEB 总是含有 EC header， 除了擦除之后到写 EC header之前的短暂时间； 而就在这短暂的时间内可能系统会发生意外重启， 导致 EC header 信息丢失或损坏。 在这种情况下， UBI 会在扫描完设备之后写一个新的 EC header， 擦除计数使用一个平均值。

The VID header is written to the PEB when UBI associates it with an LEB. Let's consider what happens to the headers in case of some UBI operations.

• The LEB un-map operation just un-maps the LEB from the PEB and schedules the PEB for erasure. When the PEB is erased, the EC header is written straight away. The VID header is not written.
• The LEB map operation or a write operation to an un-mapped LEB makes UBI find an appropriate PEB and write the VID header to it (the EC header must already be there). Note, the write operation to an already mapped LEB just writes the data straight to PEB and does not change the UBI headers.

VID header 是在 PEB 与 LEB关联之后才会写入， 想象一下针对 UBI 操作VID header会发生什么情况：

• LEB un-map 操作 -- 解除 LEB 与PEB的映射关系， 调度 PEB 进行擦除， 擦除之后写入 EC header， VID header不会写
• LEB map 操作 或 向一个un-mapped 的LEB 写数据 -- UBI 会找到合适的 PEB 然后写 VID header ； 注意， 如果是向已经mapped的LEB写数据， 会直接写数据， 而不会修改 UBI headers

UBI maintains two per-PEB headers because it needs to write different information on flash at different moments of time:

• after a PEB is erased, the EC header is written straight away, which minimizes the probability of losing the erase counter due to unclean reboots;
• when UBI associates a PEB with an LEB, the VID header is written to the PEB.

UBI 为每一个PEB 维护两个 头是因为在不同情况下需要写不同的信息:

• PEB 擦除之后， EC header 被写， 这使丢失擦除计数的可能性最小化
• 当UBI 进行 LEB 与PEB关联后， VID header 被写到 PEB

When the EC header is written to a PEB, UBI does not yet know the volume ID and LEB number this PEB will be associated with. This is why UBI needs to do two separate write operations and to have two separate headers.

当 EC header 写入到 PEB 后， UBI 此时不知到 VID 和 PEB关联的 LEB 号， 这就是 UBI 有两个header， 两次写操作的原因