ubifs物理存储

Posted 2020-08-26 yuxi_o

Ubifs通过ubi管理MTD设备，ubi的LEB随机映射PEB，其本身占用一部分PEB，具体文件存储情况分析如下。

1. Ubi中不管是是逻辑块号还是物理块号都是从0开始的。一般情况下，Nandflash开始处存放bootloader和linux，这样LEB与PEB间存在一个偏移，此偏移由ubifs起始位置确定。

2. Ubi管理整个flash（属于ubi部分的flash），ubi分区在ubi flash区域之上分配。从MTD层看，整个ubi属于同一mtd分区。

3. 在ubi中，每个PEB第一页存储EC头，第二页存储VID头，所以LED的0偏移对应PEB的4096偏移。

EC头：包含物理擦除块的擦除次数以及其它一些不太重要的信息。64bytes

VID头：包含属于这个PEB的卷ID和逻辑块号，及其它信息。512bytes

注：每个非坏的PEB都包含一个EC头和VID头，一般EC在一个擦除块的第一页，所以偏移量是0，VID在擦除块的第二页，偏移量为一页大小。

这也是逻辑擦除块小于PEB大小的原因，EC头和VID头占用了一些空间（两页大小）。

4. Ubi通过卷（volume）管理mtd分区，UBI卷分根据用途分为用户卷和内部卷，内部卷外部不可见，现UBI中只有一个内部卷：布局（layout）卷，其余全是用户卷。Layout卷存储卷表（包含每个卷信息，如卷大小、卷更新标记、卷号等），占用两个LEB。

除了卷外，ubi还要预留一些空间给其他功能使用，1个PEB用于损耗平衡，1个PEB用于原子LEB修改，一些PEB（1%，用户可配置）用于坏块处理。

5. Ubi卷存储空间分析。Ubi用户卷上一般分6个区域，sb占一个PEB（该卷的LEB0），master占用两个PEB（改卷的LEB1和LEB2），Journal区占PEB数量不定，LPT占用PEB数量在创建文件系统后确定，孤儿区一般占用一个PEB，其余PEB供main area用。

6. 应用数据存储。应用数据存储在每个用户卷的main area区，该区设计为B+树（游离树），只有叶子节点存放应用数据（文件、目录、文件数据等），其余为索引节点（用于查找最终数据）。

7. 一个ubifs卷挂载示例

[   54.707519] UBIFS: mounted UBI device 0, volume 1, name "db"

[   54.713500] UBIFS: file system size:   49520640 bytes (48360 KiB, 47 MiB, 390 LEBs)

[   54.721496] UBIFS: journal size:       6729728 bytes (6572 KiB, 6 MiB, 53 LEBs)

[   54.729125] UBIFS: media format:       w4/r0 (latest is w4/r0)

[   54.735198] UBIFS: default compressor: lzo

[   54.739471] UBIFS: reserved for root:  0 bytes (0 KiB)

[   54.744812] UBIFS DBG msg: compiled on:         Jul 20 2016 at 11:29:21

[   54.751739] UBIFS DBG msg: min. I/O unit size:  2048 bytes

[   54.757446] UBIFS DBG msg: max. write size:     2048 bytes

[   54.763153] UBIFS DBG msg: LEB size:            126976 bytes (124 KiB)

[   54.769958] UBIFS DBG msg: data journal heads:  1

[   54.774871] UBIFS DBG msg: UUID:                7B480369-82F7-49A8-BB09-71B467D8B161

[   54.782958] UBIFS DBG msg: big_lpt              0

[   54.787872] UBIFS DBG msg: log LEBs:            4 (3 - 6)

[   54.793487] UBIFS DBG msg: LPT area LEBs:       2 (7 - 8)

[   54.799102] UBIFS DBG msg: orphan area LEBs:    1 (9 - 9)

[   54.807373] UBIFS DBG msg: main area LEBs:      390 (10 - 399)

[   54.813446] UBIFS DBG msg: index LEBs:          2

[   54.818359] UBIFS DBG msg: total index bytes:   199080 (194 KiB, 0 MiB)

[   54.827362] UBIFS DBG msg: key hash type:       0

[   54.832275] UBIFS DBG msg: tree fanout:         8

[   54.837371] UBIFS DBG msg: reserved GC LEB:     13

[   54.842346] UBIFS DBG msg: first main LEB:      10

[   54.847351] UBIFS DBG msg: max. znode size      240

[   54.852416] UBIFS DBG msg: max. index node size 192

[   54.857513] UBIFS DBG msg: node sizes:    data 48, inode 160, dentry 56

[   54.864959] UBIFS DBG msg: node sizes:    trun 56, sb 4096, master 512

[   54.872314] UBIFS DBG msg: node sizes:    ref 64, cmt. start 32, orph 32

[   54.879852] UBIFS DBG msg: max. node sizes:     data 4144, inode 4256 dentry 312, idx 188

[   54.888397] UBIFS DBG msg: dead watermark:      2048

[   54.893554] UBIFS DBG msg: dark watermark:      6144

[   54.898742] UBIFS DBG msg: LEB overhead:        2656

[   54.903900] UBIFS DBG msg: max. dark space:     2396160 (2340 KiB, 2 MiB)

[   54.910980] UBIFS DBG msg: maximum bud bytes:   6221824 (6076 KiB, 5 MiB)

[   54.918060] UBIFS DBG msg: BG commit bud bytes: 5055232 (4936 KiB, 4 MiB)

[   54.927368] UBIFS DBG msg: current bud bytes    63488 (62 KiB, 0 MiB)

[   54.934082] UBIFS DBG msg: max. seq. number:    10239

[   54.939331] UBIFS DBG msg: commit number:       4