UBI - Unsorted Block Images（未排序的块图像）（1-7）

Table of contents

1. Big red note
2. Overview
3. Power-cuts tolerance
4. Kernel source code
5. Mailing list
6. User-space tools
7. UBI headers
8. UBI volume table
   • Implementation details
9. Minimum flash input/output unit
10. NAND flash sub-pages
11. UBI headers position
12. Flash space overhead
13. Saving erase counters
14. How UBI flasher should work
15. Marking eraseblocks as bad
16. Scalability issues
    • Implementation details
17. Reserved blocks for bad block handling (only for NAND chips)
18. Volume auto-resize
19. UBI operations
    1. LEB un-map
       • Implementation details
    2. LEB map
    3. Volume update
    4. Atomic LEB change
       • Implementation details
20. Fastmap
21. R/O block devices on top of UBI volumes
22. UBI stress testing
23. More documentation

Big red note

People are often confused about UBI, which is why this section was created. Please, realize that:

创建这篇文章，是因为人们经常对UBI感到困惑。请知悉：

• UBI is not a Flash Translation Layer (FTL), and it has nothing to do with FTL;
  UBI不是闪存翻译层(FTL)，与FTL无关；
• UBI works with bare flashes, and it does not work with consumer flashes like MMC, RS-MMC, eMMC, SD, mini-SD, micro-SD, CompactFlash, MemoryStick, USB flash drive, etc; instead, UBI works with raw flash devices, which are mostly found in embedded devices like mobile phones, etc.
  UBI适用于裸闪存，它不适用于MMC、RS-MMC、eMMC、SD、mini-SD、Micro-SD、CompactFlash、MemoryStick、USB闪存驱动器等消费级闪存；相反，UBI适用于原始闪存设备，这些设备大多存在于手机等嵌入式设备中。

Please, do not be confused. Read here for more information about how raw flash devices are different from FTL devices.

请不要觉得困惑。此处可以阅读更多有关裸flash设备和FTL设备的不同点（Memory Technology Device (MTD) Subsystem for Linux.）。

Overview

概述

UBI (Latin: "where?") stands for "Unsorted Block Images". It is a volume management system for raw flash devices which manages multiple logical volumes on a single physical flash device and spreads the I/O load (i.e, wear-leveling) across whole flash chip.

UBI(拉丁语意为：“在哪里？”)意为“未排序的块图像”。它是一个用于裸闪存设备的卷管理系统，它管理单个物理闪存设备上的多个逻辑卷，并在整个闪存芯片上分散I/O负载(即，损耗均衡)。

In a sense, UBI may be compared to the Logical Volume Manager (LVM). Whereas LVM maps logical sectors to physical sectors, UBI maps logical eraseblocks to physical eraseblocks. But besides the mapping, UBI implements global wear-leveling and transparent error handling.

从某种意义上说，UBI可以与逻辑卷管理器(LVM)相提并论。LVM将逻辑扇区映射到物理扇区，而UBI将逻辑擦除块映射到物理擦除块。但除了映射之外，UBI还实现了全局损耗均衡和透明的错误处理。

An UBI volume is a set of consecutive logical eraseblocks (LEBs). Each logical eraseblock is dynamically mapped to a physical eraseblock (PEB). This mapping is managed by UBI and is hidden from users and higher-level software. UBI is the base mechanism which provides global wear-leveling, per-physical eraseblock erase counters, and the ability to transparently move data from more worn-out physical eraseblocks to less worn-out ones.

一个UBI卷是一组连续的逻辑可擦除块（LEBs）。每一个逻辑可擦除块都是动态映射到物理可擦除块（PEB）。此映射由UBI负责管理，对用户和更高级别的软件隐藏。UBI是一种基本机制，它提供了全局损耗均衡，每个物理可擦除块的擦除计数器，以及透明地将数据从磨损较多的物理可擦除块移动到磨损较少的物理可擦除块。

The UBI volume size is specified when a volume is created, but may later be changed (volumes are dynamically re-sizable). There are user-space tools which may be used to manipulate UBI volumes.

在创建UBI卷时会指定卷的大小，但是在之后也可以更改（即卷是可以动态调整的）。有几个用户空间工具可以用来操控UBI卷。

There are 2 types of UBI volumes: dynamic volumes and static volumes. Static volumes are read-only and their contents are protected by CRC-32 checksums, while dynamic volumes are read-write and the upper layers (e.g., a file-system) are responsible for ensuring data integrity.

有两种类型的UBI卷：动态卷和静态卷。静态卷是只读的并且他们的内容受到CRC-32校验的保护，而动态卷是可读写的，上层（例如文件系统）负责确保数据完整性。

Static volumes are typically used for the kernel, initramfs, and dtb. Larger static volumes may incur a significant penalty when opening, as the CRC-32 needs to be calculated at this time. If you are looking to use static volumes for anything besides the kernel, initramfs, or dtb you are likely doing something wrong and would be better off using a dynamic volume instead.

静态卷通常用于kernel，initramfs和dtb。由于需要计算CRC-32，因此打开较大的静态卷时可能会很大的延时。如果您希望将静态卷用于除内核、initramfs或dtb之外的任何东西，那么您很可能做了错误的选择，最好改用动态卷。

UBI is aware of bad eraseblocks (i.e. portions of flash which wear out over time) and frees upper-level software from having to handle bad eraseblocks itself. UBI has a pool of reserved physical eraseblocks, and when a physical eraseblock becomes bad, it transparently substitutes it with a good physical eraseblock. UBI moves the data from newly discovered bad physical eraseblocks to good ones. The result is that users of UBI volumes do not notice I/O errors since UBI takes care of them transparently.

UBI可以识别坏块（即Flash中随时间磨损的部分），从而使上层的软件不必自行处理坏块。UBI有一个预留的物理可擦除块池，当一个物理可擦除块坏了，它会使用池子里一个好的块来代替坏块。UBI将新发现的坏的物理块上的数据转移到好的块上。这样做的结果是使用该UBI卷的用户不会注意到发生了输入/输出错误，因为UBI会自行处理这些错误。

NAND flashes are also susceptible to bit-flip errors which occur on read and write operations. Bit-flips are corrected by ECC checksums, but they may accumulate over time and cause data loss. UBI handles this by moving data from physical eraseblocks which have bit-flips to other physical eraseblocks. This process is called scrubbing. Scrubbing is done transparently in the background and is hidden from upper layers.

NAND Flash同样也容易受到读写操作中位反转的影响。位反转可以通过ECC校验来纠正，但是位反转可能会累计并导致数据丢失。UBI通过将数据从位反转的物理可擦除块移到其他物理可擦除块来处理位反转。这个过程叫做擦洗。擦洗同样也是后台自行运行的，对上层不可见。

Here is a short list of UBI's main features:

以下是UBI主要功能的简短列表：

• UBI provides volumes which may be dynamically created, removed, or re-sized;
  UBI卷可以动态的创建，移除，或者调整大小；
• UBI implements wear-leveling across the entire flash device (i.e., you might think you're continuously writing/erasing the same logical eraseblock of an UBI volume, but UBI will spread this to all physical eraseblocks of the flash chip);
  UBI在整个闪存设备上实现损耗均衡（即你可能认为自己一直在读/写一个UBI卷的某一个逻辑块，但其实UBI会将其扩展到闪存芯片的所有物理可擦除块）；
• UBI transparently handles bad physical eraseblocks;
  UBI会自行处理坏的物理可擦除块；
• UBI minimizes the chances of losing data by means of scrubbing.
  UBI通过擦洗的方式将丢失数据的风险降到最小

Here is a comparison of MTD partitions and UBI volumes. They are somewhat similar because:

下面是MTD分区和UBI卷的对比。他们在一定程度上有点相似，因为：

• both consist of eraseblocks - logical eraseblocks in the case of UBI volumes, and physical eraseblocks in the case of MTD partitions;
  都是由可擦除块组成——在UBI卷中是逻辑块，在MTD分区中是物理可擦除块；
• both support three basic operations: read, write, and erase.
  都支持三种基本操作：读，写，和擦除。

But UBI volumes have the following advantages over MTD partitions:

但是UBI卷对比MTD分区有以下优点：

• UBI implements wear-leveling, so users do not have to care about this at all, which means the upper level software may be simpler;
  UBI支持磨损均衡，因此用户不必关心磨损问题，这意味着上层软件可以变得更简单；
• UBI handles bad eraseblocks, which also leads to simpler upper-level software;
  UBI自行处理坏块，这同样使得上层软件更简单；
• UBI volumes are dynamic in a sense that they may be created, removed or re-sized dynamically, while MTD partitions are static;
  UBI卷在某种意义上是动态的，它们可以动态创建，删除或者调整大小，而MTD分区是静态的；
• UBI handles bit-flips which again makes the upper level software simpler;
  UBI处理位反转，这再次使得上层软件更简单；
• UBI provides a volume update operations which makes it easy to detect interrupted software updates and recover;
  UBI提供一个叫做卷更新的操作，便于检测中断的软件更新和恢复；
• UBI provides an atomic logical eraseblock change operation which allows changing the contents of a logical eraseblock without loosing the data if an unclean reboot happens during the operation; this might be very useful for the upper-level software (e.g., for a file-system);
  UBI提供原子逻辑擦除块改变操作，如果在操作期间发生意外的重启，则允许改变逻辑擦除快的内容而不会丢失数据；这对于上层软件（例如，对于文件系统）可能非常有用；
• UBI has an un-map operation, which just un-maps a logical eraseblock from the physical eraseblock, schedules the physical eraseblock for erasure, and returns; this is very quick and frees upper level software from implementing their own mechanisms to defer erasures (e.g., JFFS2 has to implement such mechanisms).
  UBI有一个取消映射操作，它只是将逻辑擦除块和物理擦除块之间的映射关系取消，调度物理擦除块进行擦除，然后返回；这非常快，并且使上层软件不必实现它们自己的机制来推迟擦除（例如，JFFS2必须实现这样的机制）。

UBI also provides a block device that allows regular, block-oriented file systems to be mounted on top of an UBI volume. This is possible because UBI handles bad-blocks transparently.

UBI还提供数据块设备，允许在UBI卷上装载常规的面向数据块的文件系统。这是可能的，因为UBI透明地处理坏块。

There is an additional driver called gluebi which emulates MTD devices on top of UBI volumes. This looks a little strange, because UBI works on top of an MTD device, then gluebi emulates other MTD devices on top, but this actually works and makes it possible for existing software (e.g., JFFS2) to run on top of UBI volumes. However, new software may benefit from the advanced UBI features and let UBI solve many issues which the flash technology imposes.

还有一个叫做 gluebi 的驱动程序，它可以在UBI卷上模拟MTD设备。这看起来有一点奇怪，因为UBI工作在MTD设备上，而 gluebi 在上面模拟MTD设备，但实际上这是有用的，并使现有软件（如JFFS2）能够在UBI卷上运行。然而，新软件可能受益于先进的UBI功能，并让UBI解决闪存技术带来的许多问题。

Power-cuts tolerance

断电容差

Both UBI and UBIFS are designed with tolerance to power-cuts in mind.

UBI和UBIFS在设计时都考虑到了对断电的容忍度。

UBI has an internal debugging infrastructure that can emulate power failures for testing. The advantage of the emulation is that it emulates power failures at the critical points where control data structures are written to the device, whereas the probability of interrupting the system at those precise moments with physical power-cut testing is rather low.

UBI有一个内部基础功能调试，可以模拟电源故障进行测试。该仿真的优点在于，它在将控制数据结构写入设备的关键点模拟电源故障。如果使用物理断电测试的话，在精确时刻中断系统的概率相当低。

Kernel source code

内核源码

UBI has been added to the main-line Linux kernel since version 2.6.22. The UBI git tree may be found at:

从2.6.22版开始，Linux内核主线就添加了UBI。UBI的GIT诊断树可在以下位置找到：

https://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git/

Mailing list

邮件名址录

You are welcome to send feed-back, bug-reports, patches, etc to the MTD mailing list.

欢迎您向MTD邮件列表发送反馈、错误报告、补丁等。（Memory Technology Device (MTD) Subsystem for Linux.）

User-space tools

用户空间工具

UBI user-space tools, as well as other MTD user-space tools, are available from the following git repository:

UBI用户空间工具，与其他MTD用户空间工具一样，可以从下面的git库中得到：

http://git.infradead.org/mtd-utils.git

This section provides information about how to compile the whole mtd-utils repository tree. You should find the UBI tools under the ubi-utils sub-directory.

本节提供有关如何编译整个mtd-utils存储库树的信息。您应该可以在ubi-utils子目录下找到UBI工具。

The repository contains the following UBI tools:

这个库包括以下几个UBI工具：

• ubinfo - provides information about UBI devices and volumes found in the system;
  ubinfo - 在系统中提供关于UBI设备和卷的信息；
• ubiattach - attaches MTD devices (which describe raw flash) with UBI which creates corresponding UBI devices;
  ubiattach - 将MTD设备(描述原始闪存)与UBI连接，创建相应的UBI设备；
• ubidetach - detaches MTD devices from UBI devices (the opposite to what ubiattach does);
  ubidetach - 将MTD设备与UBI设备分离(与ubiAttach的操作相反)；
• ubimkvol - creates UBI volumes on UBI devices;
  ubimkvol - 在UBI设备上创建UBI卷；
• ubirmvol - removes UBI volumes from UBI devices;
  ubirmvol - 从UBI设备上移除UBI卷；
• ubiblock - manages block interfaces for UBI volumes. See here for more information;
  ubiblock - 管理UBI卷的数据块接口。点击此处连接更多信息（Memory Technology Device (MTD) Subsystem for Linux.）；
• ubiupdatevol - updates UBI volumes; this tool uses the UBI volume update feature which leaves the volume in "corrupted" state if the update was interrupted; additionally, this tool may be used to wipe out UBI volumes;
  ubiupdatevol - 更新UBI卷；此工具使用UBI卷更新功能，如果更新中断，此功能会使卷处于“损坏”状态；此外，此工具还可用于清除UBI卷（更新一个NULL的ubi镜像）；
• ubicrc32 - calculates CRC-32 checksum of a file with the same initial seed as UBI would use;
  ubicrc32 - 计算一个文件的CRC-32校验值，与UBI使用相同的种子；
• ubinize - generates UBI images;
  ubinize - 生成UBI卷；
• ubiformat - formats empty flash, erases flash and preserves erase counters, flashes UBI images to MTD devices;
  ubiformat - 格式化空闪存，擦除闪存并保留擦除计数器，将UBI镜像存到MTD设备；
• mtdinfo - reports information about MTD devices found in the system.
  mtdinfo - 报告在系统中找到的MTD设备的信息；

All UBI tools support an "-h" option which prints basic usage information.

所有UBI工具都支持 “-h”选项，该选项会打印简单的使用信息。

Note, the ubiattach and ubidetach tools won't work if the kernel version is less than 2.6.25, because corresponding UBI features did not exist in these older kernels.

注意，如果版本低于2.6.25，那么 ubiattach 和 ubidetach 工具将不能工作，因为对应的UBI特性在这些更早的版本中不存在。

UBI headers

UBI头部

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

UBI在每个正常的物理可擦除块的开始位置储存了2个64字节的头部。

• erase counter header (or EC header) which contains the erase counter of the physical eraseblock (PEB) plus other information;
  erase counter header（or EC header），（记录擦除次数)，包含物理可擦除块（PEB）的擦除次数以及其他一些信息；
• volume identifier header (or VID header) which stores the volume ID and the logical eraseblock (LEB) number to which this PEB belongs.
  volume identifier header（or VID header），（记录卷的映射关系），存储卷的ID和此PEB块所属的逻辑块（LEB）号的卷标识符号头（或VID标头）。

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

这就是为什么逻辑块比物理块要小 - 因为头部要占用一部分的flash空间。

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

所有的UBI头部都受到CRC-32校验的保护。请参考Linux内核中的driver/mtd/ubi/ubi-media.h文件，了解有关头文件内容的更多信息。

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 to this section for information about scalability issues related to this.

当UBI连上一个MTD设备，它会扫描该设备，读取所有的头部，检查CRC-32校验，并在RAM中保存擦除次数和逻辑块到物理块的映射关系。与此相关的可伸缩性问题的信息，请参阅本节。

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

当UBI擦除一个PEB后，擦除次数会增加并写入EC头部。这意味着，除了在擦除之后和写入EC报头之前的短暂时间外，PEBs总是有一个有效的EC头部。如果在这个短暂的时间中发生了意外重启，这个EC头部就会丢失或者被损坏。在这种情况下，当MTD设备全部扫描完成后，UBI会写入一个新的EC头部，使用之前扫描计算出来的平均擦除次数来作为该PEB的擦除次数。

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

当UBI将PEB与LEB关联时，VID报头被写入PEB。让我们考虑一下在一些UBI操作期间头部发生了什么。

• The LEB un-map operation simply un-maps the LEB from the PEB and schedules the PEB for erasure. When the PEB is erased, the EC header is written immediately. The VID header is not written.
  LEB取消映射操作，简单地将LEB从PEB取消映射，并调度PEB进行擦除。当PEB被擦除时，EC报头被立即写入。未写入VID标头。
• The LEB map operation or a write operation to an un-mapped LEB makes UBI find an appropriate PEB and writes 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 the PEB and does not change the UBI headers.
  LEB映射操作或对未映射LEB的写入操作，会使UBI找到适当的PEB，并将VID报头写入其中(EC报头必须已经在那里)。请注意，对已映射的LEB的写入操作只会将数据直接写入PEB，而不会更改UBI报头。

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

UBI为每个PEB维护两个标头，因为它需要在不同的时刻向闪存写入不同的信息：

• after a PEB is erased, the EC header is written immediately, which minimizes the probability of losing the erase counter due to unexpected reboots;
  在擦除PEB之后，EC头部被立即写入，这最大限度地降低了由于意外重启而丢失擦除计数器的可能性；
• when UBI associates a PEB with an LEB, the VID header is written to the PEB.
  当UBI将PEB与LEB关联时，VID报头被写入PEB。

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

将EC报头写入PEB时，UBI还不知道此PEB将与之关联的卷ID或LEB编号。这就是为什么UBI需要执行两个独立的写入操作并拥有两个独立的头部。