|
在做项目的时候，发现flash芯片有异常现象，经过打印分析，发现是UBIFS方面设置有一些问题，经过查阅一部分资料，最终得到问题的答案。 在解决问题的过程中，发现打印信息比较重要，但网上并没有直接的相关资料，最后将自己总结的东西总结如下： 先看打印信息，打印信息如下： UBI: attaching mtd3 to ubi3 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: MTD device name: "data" UBI: MTD device size: 4 MiB UBI: number of good PEBs: 30 UBI: number of bad PEBs: 2 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 24 UBI: total number of reserved PEBs: 6 UBI: number of PEBs reserved for bad PEB handling: 2 UBI: max/mean erase counter: 1/1 UBI: image sequence number: 0 UBI device number 3, total 30 LEBs (3809280 bytes, 3.6 MiB), available 24 LEBs (3047424 bytes, 2.9 MiB), LEB size 126976 bytes (124.0 KiB) Junior create data volume UBI error: ubi_create_volume: cannot create volume 0, error -28 ubimkvol: error!: cannot UBI create volume error 28 (No space left on device) 可知，在UBIFS文件系统下由于申请空间过大导致文件挂载失败，进而出现这种现象。 问题分析： 在分析问题之前，需要先结合打印信息简单的了解一下UBIFS。UBIFS只工作于UBI volume之上。也可以说，UBIFS涉及了三个子系统： MTD系统，提供对flash芯片的访问接口； UBI系统，工作在MTD上，提供UBI volume； UBIFS文件系统，工作在UBI之上。 基于这种层次结构，底层MTD的物理分区（PEB）和上层逻辑分区（LEB）有映射关系，这样做的好处是在上层读写数据时不会考虑底层坏块的影响。 先看物理分区（PEB），每个PEB上都会有两个64bytes的头，这俩头部分别是EC header和VID header，对一片flash芯片而言，如果没有sub-pages，那么EC header会存储于第一个page，VID header会存储于第二个page。因此LEB要比PEB要小一些，如打印所示： UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd3 to ubi3 UBI: MTD device name: "data" UBI: MTD device size: 4 MiB UBI: number of good PEBs: 30 UBI: number of bad PEBs: 2 针对这个打印，我们可以看到，此flash芯片PEB为131072 bytes（128KiB），在4MiB的分区里共有32片PEB，其中2片PEB标记坏块。每块PEB，除去EC header和VID header所占的空间4096 bytes(可从VID header的偏移位置和data的偏移位置看出)，LEB最终容量为126976 bytes（124KiB）。 另外，UBI系统运行时，其本身也会占用一部分flash空间，从而使得用户能使用的flash容量减少。这些flash空间包括： 2片PEB用于存储卷表（volume table）。卷表是一种数据结构，包含了UBI设备上每一卷的信息，它是一系列volume table record，其中每一个记录块上包含以下信息：卷大小（volume size）、卷名（volume name）、卷类型（volume type，dynamic or static)、volume alignment、更新标记（update marker，防止数据更新发生意外打断，可以恢复)、自重整大小旗标（auto-resize flags）、CRC-32 校验和等信息。之所以保留两份卷表，是为了提高稳定性和防止出现突然断电的状况。当访问MTD设备时，UBI需要确保两个卷表是一致的，如果由于掉电或意外重启导致任何一种不一致状况，需要用较旧的卷表覆盖较新的卷表，确保一致；一旦有一个卷表损坏，可以使用另一个卷表。这俩卷表对用户来说，是不可见和不可访问的。 1片PEB用于损耗平衡（wear-leaving）。UBI支持损耗平衡，这对有限次读写的flash来说可极大提高其使用寿命。在UBI模块中，会包含一个负责实现损耗平衡的独立损耗均衡单元，这个单元依据EC header和VID header来实现对每个物理擦除块所擦除的次数和所属逻辑单元的读取，利用红黑树法对每个擦除块进行保护和移动。 1片PEB用于atomic LEB change operation（不知道是干什么的） 还有一部分PEB用于保存坏块的句柄，针对这个型号的flash，有2片PEB用于保存坏块句柄（见打印信息）。 因此，对于这个型号的flash芯片，总共要分出6片PEB用于支持UBI系统的运行。 结论 了解到了这些信息，回归到问题上来。结合打印信息可知，这个分区总共有4MiB的空间，有30片PEB可用，其中要分出6片PEB以供UBI运行时使用，还剩24片PEB用来存储数据。每片PEB可用存储124KiB的数据，也就是最大能储存24*124KiB=2976KiB（约2.9MiB）的数据，如果申请3MiB的空间，势必会因分区空间不足而导致文件挂载失败。 为此，可以考虑缩小申请空间，使其不大于2.9MiB（UBIFS只识别整数形式的GiB、MiB、KiB，修改的时候需注意这一点），这样的话，文件挂载便不会失败，问题就可以解决了。
参考资料： http://wb127.blog.51cto.com/2232662/873911 |
|
|
