基于squashfs的gluebi文件系统开发



1
UBI Development
What is UBI
1. UBI不是一个Flash Translation Layer，它和FTL没有任何关系。
2. 工作在bare flashes，它不能工作在MMC, eMMC, SD, mini-SD, micro-SD, USB flash设备上；UBI工作于raw flash devices上，大部分出现在嵌入式设备上。
Overview
UBI全称"Unsorted Block Images"。它是工作于raw flash devices之上的volume管理系统，它管理一个单一physical flash设备上的多个logical volume，能够把I/O负载均匀的分发到flash chip上。
在一定意义上，UBI可以和Logical Volume Manager相比较。LVM映射logical sector到物理sectors，UBI映射logical eraseblcok到physical eraseblocks。但是除了映射，UBI还实现了wear-leveling和透明的I/O错误管理。
一个UBI volume是一组连续的logical eraseblocks(LEBs)。每一个逻辑eraseblcok可以被映射为任意的physical eraseblock。这个映射是由UBI管理，并且对上层隐藏了global wear-leveling机制（记录per-physical eraseblock erase counters 以及透明的移动more worn-out数据到less worn-out上）。
UBI volume在创建时确定尺寸大小，也可以在日后改变（volume是dynamic re-sizable）。UBI有user-space工具可以用来管理UBI volumes。
有两种UBI volume，dynamic和static。static volumes是只读的，内容由CRC-32 checksums保护；而dynamic volume是read-write，上层负责确保数据的完整性。
UBI处理坏块，上层不需要关心坏块管理。UBI有一个保留的physical eraseblocks pool，当一个physical eraseblock变成坏块，UBI透明的用一个好的physical block替换这个坏块。UBI把新出现的physical eraseblock的数据移动到好physical eraseblock。UBI volume对发生的事毫无察觉。 NAND flash在读写操作时可能会发生bit-flips。Bit-flips通过ECC checksums纠正，但是积累到一定数据可能会发生数据丢失。UBI会移动发生bit-flips的数据到另外一个physical eraseblocks。这个过程叫scrubbing。scrubbing过程是后台的，并且对上层透明。（以上两点客户要求使用UBI的主要原因）
下面是UBI主要功能的一个短列表：
1. UBI提供动态生成，删除或re-sized的volume;
2. UBI实现全flash设备的wear-leveling(比如，你写的一个UBI volume的逻辑块，可以写入flash chip的任何physical eraseblocks);
3. UBI透明的处理所有physical eraseblocks;
4. UBI通过bit-flips使得数据丢失的可能性最小化。
下面是MTD分区和UBI volumes的比较，他们有一些相似之处：
（客户很在意这个）
1. 都是由eraseblocks组成的 - UBI volumes是逻辑eraseblocks，而MTD分区是物理的。
2. 都支持下面三个基本操作 - read, write, erase
2
但是UBI volumes和MTD分区相比有如下优点：
1. UBI volumes没有eraseblock wear-leveling 限制，所以用户不需要考虑这个，上层软件实现更简单。
2. UBI volumes没有bad eraseblocks，这也使上层软件不需要做坏块管理，因此上层软件也更简单。
3. UBI volumes是动态的，可以创建，删除和动态resize，而MTD分区是静态的。
4. UBI 处理bit-flips，同样使得上层软件更简单。
5. UBI提供volume update操作which makes it easy to detect interrupted software updates and recover。
6. UBI 提供了原子逻辑块修改操作，这个操作保证在修改logical eraseblock的内容过程中，发生unclean reboots不会造成数据丢失； 这对于上层软件可能是非常有用的
7. UBI有一个un-map操作，un-maps一个逻辑eraseblock到physical eraseblock的映射。schedules the physical eraseblock for erasure and returns；这是非常快的并且使得上层软件避免实现他们自己的机制。
现在我们使用的gluebi是一个驱动，用来在MTD设备上模拟UBI volumes。这看起来很奇怪，因为UBI工作在MTD设备之上，而gluebi又在UBI上模拟另外一个MTD设备。但是这种做法可以使我们更灵活的使用各种文件系统的特性，比如我们现在的方案是把squashfs使用gluebi的驱动写入到一个UBI volume上。这样不仅发挥了squashfs优点（高压缩、只读），而且还能充分利用UBI的坏块管理机制，延长nand flash的寿命。
UBI在每一个非坏physical eraseblcok的起始位置，储存两个小的64-byte的头：
1.erase counter header(or EC header)包含physical eraseblock 的擦除计数和一些其它重要信息；
2.volume identifier header(or VID header)储存volume ID 和逻辑eraseblock(LEB)号，这两个信息可以确定这个PEB属于哪个volume，以及逻辑位置； VID还包含了其他的一些信息。
这就是为什么eraseblocks要小于physical eraseblock ——头占据了一部分flash空间。
所有的UBI headers 使用CRC-32保护，请查阅linux源码中的：drivers/mtd/ubi/ubi-media.h文件查看header的内容。
当UBI attach到一个MTD device，首先扫描它，读所有的headers，检查CRC-32 checksums，存储erase counters和logical-to-physical eraseblock映射信息到RAM。
当UBI删除一个PEB，它写EC header，包含增加的erase count value。这意味着PEBs一直有EC header，除了从删除结束到EC header被写入的这个空档，如果在这时发生了unclean reboot，造成EC header丢失。在这种情况下，UBI写一个新的EC header，erase counter为MTD device扫描后的平均erase counter。
当UBI关联一个PEB和LEB时，VID头被写入PEB中。让我们考虑下面操作发生时，头部发生的变化：
The LEB un-map操作就是取消LEB和PEB之间的关联，PEB被erasure。PEB
3
被擦除，EC header被写入，但是VID header并没有被写入。LEB map操作或者对un-mapped LEB的写操作：UBI首先找到一个 PEB然后写如VID header（EC header一定已经存在了）。注意，对于一个已经mapped LEB的写操作，直接把数据写入PEB而不会修改UBI headers。
UBI维护着两个per-PEB头因为它需要在不同的时间写不同信息到flash上：
在PEB删除后，EC头立刻写入PEB
当一个UBI关联一个PEB和LEB时，VID头写入PEB
当EC header写入PEB，UBI并不知道这个PEB要关联的volume ID和LEB number。这就是为什么UBI需要两个写操作，来写两个分离的headers
UBI volume table
volume table是on-flash数据结构，保存着这个 UBI设备上每一个volume的信息。volume table是一个volume table records的数组，每一个record包含以下信息：
volume size;
volume name;
volume type;
volume alignment;
update maker;
auto-resize flag;
CRC - 32 checksum for this record.
每一个record描述一个UBI volume，记录在volume table array的index对应着这个记录的volume ID，比如UBI volume0被volume table的record0描述。volume table内的records数目受限于LEB尺寸，但是不能大于128。这就意味着最大的volume数目不能大于128。
每当UBI volume被创建，删除，re-sized，re-named或者updated时，相应的volume table record被修改。UBI维护着两个volume table以维护掉电发生后的可用性。
Implementation details
olume table驻留在一个特定目标的UBI volume中，叫做layout volume。这个volume包含两个LEBS - 每一个对应一个volume table的copy。layout volume是一个内部的UBI volume，user不能看到也不能访问它。当读或者写layout volume时，UBI使用和正常user volumes相同的机制。
UBI在updating volume table内容时，使用下列算法。
准备volume table在内存中的内容
un-map layout volume的LEB0
写新的volume table到LEB0
un-map layout volume的LEB1
写新的voume table到LEB1
刷新UBI工作队列，确保un-mapped LEBs对应的PEBs被删除掉。
当attaching MTD设备时，UBI确保两个volume table拷贝是相同的。unclean reboot可能会导致他们不相同，这是UBI选择LEB0的内容copy到LEB1中（因为LEB0是新的）。如果有一个volume table被损坏了，UBI会从另外一个volume
4