UBI - 扩展性问题

Unfortunately, UBI scales linearly in terms of flash size. UBI initialization time linearly depends on the number of physical eraseblocks on the flash. This means that the larger is the flash, the more time it takes for UBI to initialize (i.e., to attach the MTD device). The initialization time depends on the flash I/O speed and (slightly) on the CPU speed, because:

• UBI scans the MTD device when attaching - it reads the erase EC and VID headers from every single PEB; the headers are small (64 bytes each), so this means reading 128 bytes from each PEB in case of NOR flash or one or two NAND pages in case of NAND flash (this depends on whether the NAND flash supports sub-pages or not); this is anyway much less than JFFS2 needs to read when it mounts MTD devices, so UBI attaches MTD devices many times faster than JFFS2 would mount a file system on the same MTD device;
• UBI calculates CRC-32 checksum of each EC and VID header, which consumes CPU, although this is usually minor comparing to the flash I/O overhead.

很不幸， UBI 性能随flash size增大线性降低； UBI 初始化时间线性依赖flash上 PEB 的数量。 这意味着flash越大， UBI 初始化耗时越多。 初始化时间依赖 flash I/O 速度， 受 CPU 速度的影响不大， 因为：

• 当attach时， UBI 扫描 MTD 设备 - 读取 EC 和 VID header； 由于 header 非常小（对NOR flash 总共128 Byte， 对NAND flash 是一个或两个page),  无论如何都比 挂载MTD设备时 JFFS2 要读取的少， 因此， UBI attach MTD设备要比 JFFS2挂载文件系统快很多倍
• UBI 计算每个 EC header 和 VID header 的 CRC-32, 这需要占用 CPU， 尽管这与flash I/O 的开销没的比

Here are some figures:

• a 256MiB OneNAND flash found in Nokia N800 devices is attached for less than 1 sec; the flash does support sub-pages so UBI has to read the first 2KiB NAND page of each PEB while scanning;
• a 1GiB NAND flash found in OLPC XO-1 devices is attached for about 2 seconds; the flash is an SLC NAND and supports sub-pages, but the Cafe controller which is used in the laptop does not allow sub-page writes, so UBI has to read two 2KiB NAND pages from each PEB.

下面是一些数据：

• 256MB 的 OneNAND flash 在 Nokia N800 设备上 attach 时间不到 1 秒；  该flash 不支持子页， 因此 UBI 必须读取每一个 PEB 的前 2KB
• 1 GB 的 NAND flash 在 OLPC XO-1 设备上 attach 时间大约2秒， 该 flash 是 SLC NAND 并且支持子页， 但测试笔记本上的 Cafe 控制器不支持 子页， 因此 UBI 也必须读取每个 PEB 的前 2 KB

Implementation details

In general, UBI needs three tables to operate:

• volume table which contains per-volume information, like volume size, type, etc;
• eraseblock association (EBA) table which contains the logical-to-physical eraseblock mapping information; for example, when reading an LEB, UBI first looks up the table to find the corresponding PEB number, then reads from this PEB;
• erase counters (EC) table which contains the erase counter value for each physical eraseblock; UBI wear-leveling sub-system uses this table when it needs to find, for example, a highly worn-out LEB;

实现细节

总体来说， UBI 需要操作三个表：

• volume table  -  存储卷信息， 如size， 类型等
• 擦除块映射 table  - 存储 LEB 到 PEB 的映射信息， 如读取LEB的时候， UBI 首先查找该表找到对应的PEB， 然后从PEB读取信息
• 擦除计数 table - 存储每个 PEB 的擦除计数信息； UBI 耗损均衡子系统使用该表

The volume table is maintained on flash. It changes only when UBI volumes are created, deleted and re-sized, which are rare and not time-critical operations, and UBI can afford a slow and simple method of the volume table management.

The EBA and EC tables are changed every time an LEB is mapped to a PEB or a PEB is erased, which happens quite often and means that the table management methods should be fast and efficient.

UBI could maintain on the EBA and EC tables on the flash media, but this would inevitably involve journaling, journal replay, journal commit, etc. In other words, this would introduce a lot of complexity. But UBI would be logarithmically scalable in this case.

One of the UBI requirements was simplicity of the on-flash format, because UBI authors had to read UBI volumes from the boot-loader and they had very tough constraints on the boot-loader code size. It was basically impossible to add complex journal scanning and replay code to the boot-loader.

volume table 在 flash上维护， 它仅在 UBI volume 创建、删除、调整大小时修改； 它是很少进行且非时间敏感的操作， UBI 可以以简单方法管理该表。

擦除块映射表在 LEB 映射到 PEB 或 PEB 被擦除时都要修改， 这是经常发生的动作， 因此该表的管理要快速，高效。

如果UBI 在flash上维护擦除块映射表及 EC table， 但这不可避免的要涉及日志创建、回放、提交等。 换句话说， 这会引入复杂性， 但UBI 算法是对数级别的。

UBI 的一个要求是 flash 上格式的简洁性， 由于 UBI 作者必须从 boot-loader 读取 UBI 卷， 他们对 boot-loader 的代码规模几乎没任何约束， 向boot-loader 中添加任何日志扫描或回放代码基本上是不可能的。

So UBI does not maintain the EBA and EC tables on the flash media. Instead, it builds them in RAM each time it attaches the MTD device. This means that UBI has to scan whole flash and read the EC and VID headers from each PEB in order to build in-RAM EC and EBA tables.

The drawbacks of this design are poor scalability and relatively high overhead on NAND flashes (e.g., the overhead is 1.5%-3% of flash space in case of a NAND flash with 2KiB NAND page and 128KiB eraseblock). The advantages are simple binary format and robustness, as the result of simplicity.

Nonetheless, it is always possible to create UBI2 which would maintain the tables in separate flash areas. UBI2 would not be compatible with UBI because of completely different on-flash formats, but the user interfaces would stay the same, which would guarantee compatibility of all the software built on top of UBI.

因此， UBI 不在flash上维护擦除块映射表和 EC tables， 相反， 每次attach设备时它在RAM中构建它们。 这意味着 UBI 必须扫描整个flash来读取 EC 和 VID header。

这样设计的缺点是扩展性差， 相对较高的维护成本。 优点是简单的二进制格式和稳定性。

但是， 将来还是有可能创建一个 UBI2， 实现在 flash 上维护这些表，不过 UBI2 就与UBI不兼容了， flash格式不同了， 但用户接口是一致的， 这能保证运行在 UBI 上的软件的兼容性。