ubi设计

小鱼儿 2021-11-17 23:52 476阅读 0赞

原文网址：[ubi设计\_IT利刃出鞘的博客-CSDN博客][ubi_IT_-CSDN]

# 参考文档 #

**[《UBI-Unsorted Block Images》][UBI-Unsorted Block Images]**

[Memory Technology Device (MTD) Subsystem for Linux.][Memory Technology Device _MTD_ Subsystem for Linux.]

[UBI（上边网址的翻译）][UBI]

本文对第一个参考文档部分内容进行翻译，且添加自己的理解。

设计方法包括两个部分，基础部分和扩展功能。基础部分设计比较简单，直截了当。但是在伸缩性方面有些限制。扩展部分是基于基础部分，不改变接口，并向后兼容。

# **擦除块分配** #

## **基础功能** ##

UBI卷中的每一个擦除块都对于flash上的一个物理块。尽管逻辑块是连续的，但物理上不一定是连续的。  
UBI使用一张表，叫EAT表（the eraseblock assignement table）来记录逻辑块到物理块的映射关系。当分配一个物理块的时候，EAT对于的项也会修改。当一个物理块使用频繁的时候，ubi会把该块分配给另外一个物理块，此时也要修改EAT。  
EAT表是在内存中维护的。EAT是在启动扫描阶段建立的。对于flash的容量，扫描过程耗时还是可以接受的。扫描的时候只需要读取header分析其内容。

## **增强功能** ##

当然也可以实现更加全面的EAT管理，可以把EAT存储到flash中。  
此时扫描整个flash就只是一个备选方案，只有当EAT表出现异常的时候才去扫描flash。  
UBI管理一个内部的EAT卷，这个EAT卷是一个动态卷。由于磨损均衡的原因，存储EAT的物理块会改变，但是要保证在接近Flash起始位置或结束位置，这样保证flash扫描的时候可以发现EAT卷。  
基于EAT的FLASH的一个重大挑战是，连续性、访问速度以及低FLASH更新频率（low FLASH update frequency）之间的平衡折中。以下是一个折中算法：UBI写一个EAT表到flash，这个表包含了真实的块引用和很多的擦除块引用（这些块引用必须在UBI设备的初始化过程被扫描）。在扫描之前，这些擦除块的内容是未知的。这些块指的是在table写入到FLASH中时，那些处于空闲块池（free block pool）中的块。这些块是UBI给出到UBI客户端的一些用于新用途的。扫描的过程中，UBI要么添加或者更新在FLASH table中的块引用。  
这个table在以下情况下必须更新：  
1、当要求进行扫描的块用光了，UBI必须从空闲块池添加新的块到这个列表的时候  
2、table大更新发生，比如添加、删除、更新卷等操作  
3、负载均衡要求擦除块表的大修正

# **擦除块header** #

基础flash管理是基于擦除块。UBI要求同样大小的擦除块。UBI通过block header来管理块，header存储在块的开头。header有两个作用：  
1. 统计块擦除次数  
2. 卷识别  
因此有两种类型的header：  
1. 块计数header ec\_header  
2. 卷信息header volume\_header  
两种头信息独立的写入到flash中，ubi需要执行两次写操作，才能把两个header都写到flash中去。比如说，一个物理块没有分配给任何一个卷，那么他就只有一个ec\_header。一旦这个物理块被分配给某个卷，那么就立即写入vol\_header。由此也可以知道两个header在不同的page。  
ec\_header有固定的位置（在第一个page），vol\_header在接下去的一个page。 这样可以节省scan的时间。另外保持页缓存大小对齐。

## **header格式** ##

所有UBI header都是以大端格式写入flash的。这样允许可移动设备在不同系统中进行使用。UBI支持分析工具来分析裸flash数据、创建UBI镜像、单独写入目标设备。  
struct ubi\_ec\_hdr \{  
\_\_be32 magic; //0x55424921 "UBI\#"  
\_\_u8 version;  
\_\_u8 padding1\[3\]; //保留字段  
\_\_be64 ec; /\* Warning: the current limit is 31-bit anyway! \*/  
\_\_be32 vid\_hdr\_offset; //VID起始地址  
\_\_be32 data\_offset; //用户数据起始地址  
\_\_be32 image\_seq; //镜像序号  
\_\_u8 padding2\[32\];  
\_\_be32 hdr\_crc; //CRC校验值  
\} \_\_packed;  
  
struct ubi\_vid\_hdr \{  
\_\_be32 magic; //0x55424921 "UBI!"  
\_\_u8 version;  
\_\_u8 vol\_type; //卷类型，动态还是静态  
\_\_u8 copy\_flag; //如果这个逻辑块是从另一个物理块拷贝而来的  
\_\_u8 compat; //兼容性  
\_\_be32 vol\_id; //卷ID  
\_\_be32 lnum; //该物理块的逻辑块号  
\_\_u8 padding1\[4\];  
\_\_be32 data\_size; //逻辑块内有效数据长度，静态卷的时候用  
\_\_be32 used\_ebs; //卷内使用了多少逻辑块，静态卷一致性检查  
\_\_be32 data\_pad; //最后一个逻辑块有多少数据没有使用，静态卷的时候用  
\_\_be32 data\_crc;  
\_\_u8 padding2\[4\];  
\_\_be64 sqnum; //序号，该VID header创建时序号，每次分配VID header时会递增，用来识别新旧VID header  
\_\_u8 padding3\[12\];  
\_\_be32 hdr\_crc;  
\} \_\_packed;

## **ec\_header的自动更新** ##

当一个块需要被擦除的时候，它的ec会保存在RAM中，而在擦除完成后从新写入到块中。当在写入ec前出现意外，ec\_count丢失了。那么会写一个所有ec\_count的平均值。ec\_header损坏的时候也是这么处理的。 以后可能会使用日志来保存ec。

## **空间计算** ##

有效空间的计算方式：  
用户空间块 = 所有块 - UBI内部块 ubi内部块 = 坏块保留坏 + 内部卷使用的块  
可用容量 = 用户块 \* 块内可用数据  
块内保留数据 = 2 \* （sizeof）ec\_header （Nor）  
块内保留数据 = Nand Page size （Nand）

# **卷（volume）** #

有两种ubi卷，动态卷和静态卷。 静态卷只读，由CRC32校验和保护；动态卷是可读写的，数据完整性由上层负责。默认情况下，在执行ubiformat命令时，会将其格式化为动态卷。  
根据用途，UBI卷可分为用户卷和内部卷，内部卷外部不可见，仅供UBI内部使用，现在UBI中只有一个内部卷：布局（layout）卷，其余全是用户卷。布局卷存储ubi相关的信息、卷信息和块分配表。  
卷的数量在0-65535之间，在header中可以存储更大的卷序号，但是没有必要，因为用不到那么多。0-65279给用户卷，65280-65535给内部卷。卷的名字以“ubi-”开头，

## **布局卷** ##

卷65280是布局卷（卷名为 “ubi-layout”（ubiformat时，卷名是"layout volume"）），布局卷包含以下重要内容：  
1. UBI布局信息  
2. 卷数量、大小和内容  
3. 块分配表（volume table）  
布局卷会在卷创建、删除、修改大小的时候更新。任意一个操作都会引起一个新的布局卷写入flash。逻辑块的版本号就一直增加。当数据成功写入，原始的布局卷就被擦除了。  
布局卷需要**两个block**，数据以冗余方式进行存储。卷信息以一个链表的形式连续存储在卷当中。结构体如下：  
struct ubi\_vol\_tbl\_record \{  
ubi32\_t reserved\_pebs;  
ubi32\_t alignment;  
ubi32\_t data\_pad;  
uint8\_t vol\_type;  
uint8\_t padding1;  
ubi16\_t name\_len;  
uint8\_t name\[UBI\_VOL\_NAME\_MAX + 1\];  
uint8\_t padding2\[24\];  
ubi32\_t crc;  
\} \_\_attribute\_\_ ((packed));  
  
/\*  
\* Starting ID of internal volumes: 0x7fffefff.  
\* There is reserved room for 4096 internal volumes.  
\*/  
\#define UBI\_INTERNAL\_VOL\_START (0x7FFFFFFF - 4096)  
新的ubi中，卷号最大是0x7fffefff，预留4096给ubi系统。

## **鲁棒性** ##

映射卷出现问题的时候，ubi驱动会通过扫描获取卷大小、卷内保留块数量被设置为卷内扫描到的最大的逻辑块号。这将允许系统可以正常运行。UBI向系统日志发出适当的警告通过sysfs接口提供状态信息。

## **动态卷** ##

动态卷是可读写的，该数据完整性由上层负责。当需要写一个逻辑块的操作如下：生成CRC，把CRC写入新的逻辑块内，更新VID header的版本，复制块的内有效数据到新的逻辑块。如果复制数据过程中断电，ubi会优先使用版本更高的。如果新的逻辑块CRC有问题，那么又会去使用旧的。

## **静态卷** ##

静态卷只读，由CRC32校验和保护。 静态卷的块更新原理比较简单：复制VID header，写VID header的version成员（块版本号），更新header中的CRC，数据CRC不变，数据拷贝到新的block，擦除原来的块。 万一在拷贝数据的时候断电了，那么ubi可以检测到两个版本的header，于是就会选择版本高的，然后擦除低版本的block。但如果高版本的块内CRC不对，那么就用低版本的。 在移动数据过程中，无法访问被移动的块的内容。

# **卷管理** #

UBI的卷管理是基于空间计算。给用户的块数量不能超过总的块数。  
ubi实现三个卷操作：卷创建、卷删除、卷大小调整 。

## **创建卷** ##

当有足够的空闲空间才能创建出一个卷。为了在ubi之上支持块设备层，有必要提供一个参数来调整最小不能用空间。也就是2\*（sizeof ubi header），来确保一个擦除块的可用空间是块设备的整数倍。

## **删除卷** ##

可以删除一个不再使用的卷。卷的块会被擦除，然后重新放入空闲块池子中。布局卷中修改的内容必须在块被完成擦除之后进行。

## **卷大小调整** ##

一个存在的卷可以调整大小，当他不再使用的时候。 扩大卷大小的时候，必须有空闲块。 缩小卷容量的时候，卷内可用数据必须小于等于缩小后的容量。 ubi一般不会减小动态卷容量，除非减小的地方都是没有用到的块。卷大小减小时，已经使用了的部分必须比新的卷大小要小，或者相等。默认的，UBI不会减小动态卷的大小，除非将要移除的那些编号范围内的逻辑擦除块仅包含未使用的块。一个具体的参数可覆盖这个默认情况。在调整卷大小之前，UBI将移动那些将被移除的编号范围内的逻辑块的内容到未使用的逻辑擦除块。移动操作必须在卷大小信息传播到布局卷之前完成。

# **逻辑块** #

一个ubi卷由逻辑块构成，其容量由创建的时候指定。一个卷内的逻辑块块号从0到max-1.这些块号在卷内是唯一的。 有时候会出现短暂的另类块号，比如在数据转移、磨损均衡或者块考验过程。UBI会确保不会访问到这样块号的块。

**卷更新**  
UBI卷的更新来自用户空间。更新机制写入没有元信息的原始数据内容。元信息 - 即卷头 - 由UBI创建。更新工具打开ubi卷并发出一个start\_update 的ioctl命令。 start\_update的参数是将写入卷的总字节数。这对提供更新的可靠性与中断更新以及计算静态卷的总使用块的数量是必要的。UBI会检查所请求的数据长度是否已经进入该卷。  
在更新动态UBI卷的情况下，首先使用包含保留的VOLUME\_UPDATE卷ID和逻辑块编号0的卷更新头写入块。被更新的卷的编号存储在该块的数据有效载荷中。此块的存在表示正在进行更新。 UBI擦除分配给卷的最终现有块。在写入新的内容之前，必须完成现有块的擦除。 静态卷更新时，不需要写入卷更新标记。如果找到所有使用的擦除块并且它们的头部和数据CRC是正确的，则确保数据的完整性和正确性。  
现在，数据内容被写入，UBI为逻辑擦除块创建卷头，并在静态卷的情况下计算数据CRC。 当动态卷的所有数据已经写入成功时，则更新卷块被擦除。 请注意，给予start\_update命令0字节的大小是有效的。这将创建正在进行的更新块并擦除现有的逻辑擦除块。在所有现有块被擦除之后，正在进行的更新标记被移除。这对清空卷很有用。当卷更新中断时，具有保留的更新卷ID的块位于FLASH上，并使受保护的卷的所有其他最终存在的逻辑擦除块无效。一个新的更新必须开始。尝试访问这样的卷的可能的UBI客户端被通知.  
一个适当的错误代码和访问被拒绝。另请参见“编程接口”。在卷布局中，卷仍然存在，但是使用块的数量为零。 UBI会自动擦除这个卷的最终存在的块，但是指示卷更新的块不是 擦除。用户交互是解决这个问题所必需的。进行中的更新块可以通过新的更新命令或通过删除卷来删除。 使用额外的擦除块来指示正在进行的更新看起来像是浪费，但是对于动态内容卷来说，在允许使用这样的卷之前，没有其他方式来确保更新操作的完整性。这可能会改变一个杂志/超级块的增强 已经实施。另一方面，正在进行更新的标记是完全合理的，因为这样的更新在设备的生命周期中很少发生，并且它允许基于扫描的体积完整性的标识，例如在引导装载程序中。 请注意，额外的块是每个UBI设备开销，为了磨损平衡和块移动的目的而保留。这将并发卷更新的数量限制为一个。这不是一个大问题，因为卷更新通常是在代码更新的情况下完成的，时间不是关键 因子。此外，更新的限制因素是FLASH设备本身不允许并行擦除/编程操作。卷的部分更新是不可能的。

# **块管理** #

## **保留块** ##

ubi需要保留一些块来确保操作。这导致了flash可用块的减少。 最小的要求是UBI需要一个块给磨损均衡和更新机制。NandFlash还需要保留一部分给坏块。最多的数量是设计者为保证UBI的全部操作。这是每个ubi设备的坏块总数。计算卷容量的时候，没有必要把坏块算进去。配置坏块保留块，UBI保证完整的功能。

## **坏块参数**  ##

最大的坏块数量跟Flash类型和flash容量有关。扩展mtd info结构来保存最大坏块数量是可以接受的。

## **鲁棒性** ##

坏块数量超过了最大值，那么UBI就会拒绝写操作。手动交互是必须的。解决办法是增加最大坏块数限制。UBI设备还有空闲空间的时候，这是唯一的办法。如果所有空间都用掉了，那么在最大坏块限制增加之前，卷将无法删除或者改变大小。 实际的坏块数量可以通过proc接口查询到。 当坏块最大限制和实际坏块数量差小于2的时候，ubi会写警告信息到系统日志中。 建议通过UBI设备的sysfs接口来监控坏块的实际数量监视应用程序。这使得服务的早期信息可以确保设备的使用在达到最大数量的坏块之前，可以替换或更改参数。设备被切换到一个受限的操作状态。

## **块分配** ##

ubi采用推迟块分配来确保最优的磨损均衡。当向一个不存在的逻辑块写数据的时候，就会分配一个块，并且写入VID header。没有被分配的块就待在空闲池中。

## **块擦除** ##

引起块擦除的操作： ubi的擦除请求、卷删除、卷内容更新、磨损均衡、位反转（块考验）。 在大部分情况中，擦除是异步操作。由后台进程完成。同步操作只是标记了块擦除标志。

## **块内容迁移** ##

引起块内容迁移的操作：磨损均衡、位翻转（考验块）、卷大小修改。大部分情况，块的数据转移操作是异步的，并且是由一个后台程序来完成的。 当一个逻辑块的内数据需要搬移到另一个物理块中时（磨损均衡或者位反转），需要完成： 把当前块中的数据复制到另一个物理块中、更新EAT表、擦除旧的块

## **块考验（scrubbing）** ##

scrubbing是一个安全的机制：处理位反转。当1个位反转发生并且ECC算法能够恢复原始的数据内容，然后受影响的块的内容会根据算法移动到一个空闲的块。当一个kernel或者用户空间发起的读操作检测到了一个位反转，scrubbing操作就会被安排（scheduled）到后台。  
下图展示了文件系统的volume的UBI block被处理的：当一个位错误（UBI block A）发生之后，需要被拷贝到一个空闲的块来消除位错误。增加版本号，计算CRC并添加到新UBI header。因为这种特定的UBI block被正在使用它的文件系统控制，CRC一般不使用（unused）。但是当块被scrubbed时，计算data CRC，用来识别这个块的最新的有效版本，此时拷贝或者擦除操作会被打断。

![UBI图片4.2][UBI_4.2]

\- 假设block A和block B同时存在。只有data CRC是有效的时候，有最高版本号的块被保持。两个块都存在是以下原因  
导致的：删除block A之前或者正在删除block A时产生了中断（interruption）。如果在删除block A时产生了中断，  
block A有未定义数据而block B仍然有效。  
\- 当文件系统需要向non-empty block添加内容时会发生block B到block C的转换。这种情况下，data CRC变为无效的。  
当有两个块存在时，只有比较新的块的data CRC会被检查。在下一步将会看到。  
\- block C发生了1位错误，它现在需要被拷贝到一个新块（block D）。这种情况和第一种情况相同。此时会计算data  
CRC、版本号增加1、写入新的block D。如果被打断的block C和D同时存在，比较新的block D的CRC被用来判断  
它的有效性。如果D的CRC是无效的则使用C。

上边展示出来的算法保证了在任意scrubbing操作被打断的情况下，可以通过block的版本号和/或相关的data CRC来识别出有效的UBI block的拷贝。

# **UBI初始化** #

ubi首先是扫描全flash找到布局卷的位置，来建立EAT表。当ubi扫描flash的时候，回去读ec\_header，然后在内存中建立必要的结构。  
基于扫描的机制需要在引导加载程序和内核中进行单独的扫描。 将引导加载程序扫描表交给内核在技术上是可行的，但这需要在不同的体系结构和主板上使用更加统一的引导加载程序内核接口。 这样的界面是不可用的，因此这样的尝试将是一个单一的目的，而不是一个有用的通用解决方案。  
后续改进：为了避免扫描整个flash，需要建立flash上的EAT表。

# **后台操作** #

ubi使用后台线程或者工作队列实现以下操作：

1.  磨损均衡
2.  块转移
3.  块考验
4.  块擦除

# **磨损均衡** #

磨损均衡的实现依靠块擦除次数（erase count）。  
默认的选择标准是选擦除次数最少的块。  
ubi一直跟踪所有块中擦除次数最多和最少的块。为了避免永久磨损均衡活动，引入了擦除次数阈值（5000）。  
在每一次擦除一个块都会去检查磨损均衡的情况。当新擦除块是擦除次数最多的块时，若擦除次数相对于具有最低  
擦除计数的块的差值已经达到阈值，则UBI选择具有低擦除计数的长期存储块，并使用块移动功能将块内容复制到  
具有高擦除计数的块。当块拷贝动作完成后，就擦除块擦除最少的块并把它放到空闲块池中。如果空闲块数量  
非常少，则可能会减慢UBI客户端的擦除块的分配。  
空闲-未分配-擦除块有一个列表记录了其擦除次数，以便分配块的时候可以选择。  
**改进**   
UBI客户端可能会提供一个回调函数，它在尝试移动块之前由UBI调用。该功能的基本原理是，客户可能会  
否决块内容的移动。 一个原因可能是客户端正在用这个块进行写操作或这个块已经有垃圾回收计划。 在这种情况下，块内  
容的移动是没有意义的，可以推迟到到稍后的时间或者在近期通过垃圾回收使这个块可用。  
可以实现用信号通知逻辑擦除块的预期用途的功能。 UBI客户可以表示该块是用于长期存储还是短期存储。这样能允许有更有效的磨损均衡算法。

**磨损均衡代码分析**

相关函数：ensure\_wear\_leveling  
它只要是来判断 UBI 设备是否需要进行均衡损耗的相关处理，这儿就有两个问题了： 1.它判断的依据是什么。 2.它会进行什么样的相关来避免对一个可擦出块进行过多的擦除操作。  
第一个问题：在 WL 子系统中，所有的可擦出块都归 WL 子系统来进行管理。这是一个 RB 树，我们来其中的每一个结点。  
struct ubi\_wl\_entry \{  
union \{  
struct rb\_node rb;  
struct list\_head list;  
\} u;  
int ec;  
int pnum;  
\};  
也就是：WL 只关心一个东西， ec 的值。下面是 wear\_leveling\_worker 函数中的一段核心代码：  
e1 = rb\_entry(rb\_first(&ubi->used), struct ubi\_wl\_entry, u.rb);  
e2 = find\_wl\_entry(&ubi->free, WL\_FREE\_MAX\_DIFF);  
if (!(e2->ec - e1->ec >= UBI\_WL\_THRESHOLD))  
从 used 队列中取出一个 LEB，显然 EC 是最小的（每擦除一次， EC 值加一），再从 free队列中取出一个 EC 值最大的 LEB。  
若两个 LEB 的 ec 差值大于 UBI\_WL\_THRESHOLD，则进行 WL 操作：将内容从一个 LEB 搬到另外一个 LEB 中去：  
err = ubi\_eba\_copy\_leb(ubi, e1->pnum, e2->pnum, vid\_hdr);  
解析： 将used红黑树中的第一个LEB的数据搬到free红黑树中EC值最大（剩余寿命最短）的LEB中。这样一来，寿命最短的会放到used中，大大减小擦除次数。

[ubi_IT_-CSDN]: https://knife.blog.csdn.net/article/details/97898149
[UBI-Unsorted Block Images]: http://blog.chinaunix.net/attachment/attach/23/14/19/142314191497d9492e204a158a5f12f4489772e55e.pdf
[Memory Technology Device _MTD_ Subsystem for Linux.]: http://www.linux-mtd.infradead.org/doc/ubi.html
[UBI]: https://blog.csdn.net/kickxxx/article/details/6707589
[UBI_4.2]: /images/20211116/55aced9c7d0b4ea489d01f5054713207.png