UBIFS
無排序區塊鏡像文件系統(Unsorted Block Image File System, UBIFS)是用於固態存儲設備上，並與LogFS相互競爭，作為JFFS2的后繼文件系統之一。真正開始開發於2007年，並於2008年10月第一次加入穩定版本於Linux核心2.6.27版。
由IBM、nokia工程師Thomas Gleixner、Artem Bityutskiy等人於2006年發起，致力於開發性能卓越、擴展性高的FLASH專用文件系統，以解決嵌入式環境下以FLASH作為MTD設備使用時的技術瓶頸。
在設計與性能上均較YAFFS2、JFFS2更實用於MLC NAND FLASH。
1. UBI layer
UBIFS涉及三個子系統：
>MTD系統，提供對各種flash芯片的訪問接口；drivers/mtd
>UBI系統，工作在MTD上，提供UBI volume；drivers/mtd/ubi
>UBIFS文件系統，工作在UBI之上；fs/ubifs
UBI指的是UBI subsystem，其工作在MTD設備上，是MTD設備的高層次表示，對上屏蔽了一些MTD需要處理的問題，如wearing和壞塊處理；而UBIFS指的是UBIFS file system，工作在UBI卷層之上。
2. UBI
ubi provide logical volumes instead of MTD partitions
ubi volumes are in a way similar to LVM volumes
ubi volumes may be dynamcially created, deleted and re-sized
ubi does wear-leveling(磨損平衡算法) across whole MTD device
Wear-leveling is done by UBI, not by the UBI user
3. UBI volume vs MTD partition
底層MTD的物理分區（PEB）和上層邏輯分區（LEB）有映射關系，這樣做的好處是在上層讀寫數據時不會考慮底層壞塊的影響。
4. volume update operation
Volume is in “corrupted” state if update is interrupted
“corrupted” volumes are not usable and must be updated
Dynamic volumes are read-write
Static volumes are read-only
Static volumes are protected by CRC-32 checksum
5. 如何掛載ubi文件系統
UBI character devices:
a) /dev/ubi0, /dev/ubi1, … – UBI devices: volume create, delete, re-size, and get device description operations
b) /dev/ubi0_0, /dev/ubi0_1, … - UBI volumes: read, write, update, and get volume description operations
UBI sysfs interface: /sys/class/ubi
UBI in-kernel interface: include/linux/mtd/ubi.h
Linux 系統中有關mtd和ubi的接口：
(1) cat /proc/mtd：可以看到當前系統的各個mtd情況，
(2) cat /proc/partitions: 分區信息，有上面的類似
(3) cat /sys/class/ubi/ubi0/*：當前系系統的ubi情況
(4) ls /dev/*, 查看設備節點
假設我們想在mtdblock1上加載ubifs文件系統，步驟如下：
(1)./ubiformat /dev/mtd1 -----格式化mtdblock1
(2)./ubiattach /dev/ubi_ctrl -m 1 -----將mtdblock1與ubi建立連接，命令輸出如下：
[ 977.342492] UBI: attaching mtd1 to ubi2
[ 977.346417] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 977.352631] UBI: logical eraseblock size: 126976 bytes
[ 977.357948] UBI: smallest flash I/O unit: 2048
UBI device number 2, total 2000 LEBs (253952000 bytes, 242.2 MiB), available 1976 LEBs (250904576 bytes, 239.3 MiB), LEB size 126976 bytes (124.0 KiB)
系統自動將mtd1關連到ubi2上，假設系統中已經存在ubi0, ubi1了。
(3) ls /sys/class/ubi/ -----可以看到該目錄下增加了一個ubi2的子目錄
(4) cat /sys/class/ubi/ubi2/dev -----可以得到該ubi2設備的主次設備號，如249：0
(5) cat /sys/class/ubi/ubi2/volumes_count -----結果為0，表示該ubi上沒有任何volume
(6) ls /dev/ubi* -----如果/dev中沒有ubi2, 則手工創建“mknod /dev/ubi2 c 249 0”
(7) ./ubimkvol /dev/ubi2 -s 100MiB -N my_ubi_vol -----在ubi2上創建一個volume
(8) ls /sys/class/ubi/ -----可以看到該目錄下增加一個ubi2_0的目錄，代表ubi2上的第一個volume,如果“cat /sys/class/ubi/ubi2_0/name”， 你可以得到“my_ubi_vol”，這就是（7）中的名字。
(9) cat /sys/class/ubi/ubi2_0/dev -----得到該volume的主次設備號，如249：1
(10) mknod /dev/ubi2_0 c 249 1 -----如果/dev中沒有ubi2_0, 則需要手工創建
(11) mount -t ubifs ubi2_0 /mnt -----將ubi2_0掛載到本地目錄 /mnt上，
(12) mount -----可以看到ubi2_0成功掛載在/mnt上。
linux源碼中Documentation/filesystems/ubifs.txt中含有ubifs mount的用法：
Mount options
=============
(*) == default.
bulk_read read more in one go to take advantage of flash media that read faster sequentially
no_bulk_read (*) do not bulk-read
no_chk_data_crc skip checking of CRCs on data nodes in order to
improve read performance. Use this option only
if the flash media is highly reliable. The effect
of this option is that corruption of the contents
of a file can go unnoticed.
chk_data_crc (*) do not skip checking CRCs on data nodes
compr=none override default compressor and set it to "none"
compr=lzo override default compressor and set it to "lzo"
compr=zlib override default compressor and set it to "zlib"
Quick usage instructions
========================
The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax, where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is UBI volume name.
Mount volume 0 on UBI device 0 to /mnt/ubifs:
$ mount -t ubifs ubi0_0 /mnt/ubifs
Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume name):
$ mount -t ubifs ubi0:rootfs /mnt/ubifs
The following is an example of the kernel boot arguments to attach mtd0 to UBI and mount volume "rootfs":
ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
6. ubi簡介
ubi子系統可以理解為ubifs的驅動層，它在文件系統層和MTD層之間起到銜接作用。主要負責以下幾個功能：
》LEB到PEB的映射；》壞塊的回收；》物理擦除塊損耗均衡處理；》處理位翻轉現象；》銜接MTD設備到UBI；》創建UBI卷；》掛載UBI文件系統
UBI子系統重要的數據結構
》UBI卷表、UBI卷
》LEB擦除塊頭：EC頭、VID頭
》EC表、EBA表；(在內存中構建)
》損耗均衡模塊
UBI卷
可分為靜態卷和動態卷，靜態卷只讀，由CRC32校驗和保護；動態卷是可讀寫的，該數據完整性由上層負責。根據用途，UBI卷可分為用戶卷和內部卷，內部卷外部不可見，僅供UBI內部使用，現在UBI中只有一個內部卷：布局（layout）卷，其余全是用戶卷。
volume表：包含每個卷信息，比如卷的大小、卷更新標記、卷號等。維護在flash上，volume表存儲在layout卷中，layout卷包含兩個LEB，每個LEB都包含一份volume表。volume表僅在ubi卷被創建、刪除和重定義大小時改變。
EBA（Erase Block Association，擦除塊關聯）表：所有LEB到PEB的映射信息。
EC（Erase Counter，擦除計數）表：EC表包含着每一個PEB的擦寫次數。
EBA和EC表是在每次掛載MTD設備時建立，這也意味着UBI必須掃描整個Flash，從每個PEB讀取VID和EC頭部以構造EBA和EC表。相對於volume表，EBA和EC表變動較大，因為每次對PEB寫時都有可能修改表。每個UBI卷都有一個EBA表，用eba_tbl結構表示。
EBA表的map和unmap操作
對EBA表最重要的操作是map和unmap，map過程是首先找到相應的PEB，然后將VID頭寫入PEB，然后修改內存中相應的EBA表。unmap首先解除LEB與相應PEB的映射，然后調度擦除該PEB，unmap並不會等到擦除完成，該擦除由UBI后台進程負責。
EC頭：包含物理擦除塊的擦除次數以及其它一些不太重要的信息。64bytes
VID頭：包含屬於這個PEB的卷ID和邏輯塊號，及其它信息。512bytes
注：每個非壞的PEB都包含一個EC頭和VID頭，一般EC在一個擦除塊的第一頁，所以偏移量是0，VID在擦除塊的第二頁，偏移量為一頁大小。
這也是邏輯擦除塊小於PEB大小的原因，EC頭和VID頭占用了一些空間（兩頁大小）。
UBI運行的時候需要占用一部分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-leveling）。UBI支持損耗平衡，這對有限次讀寫的flash來說可極大提高其使用壽命。在UBI模塊中，會包含一個負責實現損耗平衡的獨立損耗均衡單元，這個單元依據EC header和VID header來實現對每個物理擦除塊所擦除的次數和所屬邏輯單元的讀取，利用紅黑樹法對每個擦除塊進行保護和移動。
1片PEB用於atomic LEB change operation。
一部分PEB用於保存壞塊的句柄。
7. UBIFS簡介
UBIFS文件系統運行在UBI系統之上，它會把UBI volume划分為6個部分：
超級塊（superblock area），使用LEB0區塊。它在文件系統創建時建立，占用一片LEB存儲uperblock node，一般來說，superblock node保存文件系統很少變化的參數。superblock node僅僅占用LEB0的前4096個字節。superblock幾乎不改變，只有一種情況會導致superblock node被重寫，就是自動resize時。之所以需要自動resize，是因為創建ubifs文件系統鏡像時，並不知道將要mount的UBI bolume的大小，所以當我們將UBIFS鏡像安裝到UBI上時，UBI的尺寸可能實際上小於UBIFS鏡像所需要的最大空間，此時就需要把UBIFS resize以適合UBI volume。存儲配置信息，如索引樹扇出（indexing tree fanout）、壓縮類型等，在mount時被讀。
主節點區（master area），占用LEB1和LEB2兩個分區。一般情況下，這兩個LEBs保存着相同數據，master node尺寸為512 bytes，每次寫入master node會順序的使用LEB的空閑page，直到沒有空閑page時，再從offset zero開始寫master node，這時會重新unmapped LEBs為另一個erased LEB。注意，master node不會同時unmapped兩個LEBs，因為這會導致文件系統沒有有效master node，如果此時掉電，系統無法找到有效master node。master區域中每個master node指向一個索引的root node，這樣就只需要在掛載的時候掃描master area便可以得到所有文件的信息。主節點存儲着所有flash上沒有固定邏輯位置的結構的位置（The master node stores the position of all on-flash structures that are not at fixed logical positions.）。
日志區間（Journal/log area，或commit area），從LEB3開始，占用空間不確定。UBIFS使用日志的目的是為了減少對flash index（main area區的文件的索引，實際索引）的更新頻率，因為更新文件系統時，一旦添加葉子節點，整個文件系統的索引節點都要定期更新，這樣的話會非常影響效率。因此采用日志區間，當添加葉子節點時，會先將其添加到日志中，只更新內存中的節點，不再提交到flash中，然后再定期提交日志，這樣的話，效率會有極大的提高。當需要修改索引樹葉節點時並不會馬上更新flash上的索引樹，首先要更新RAM中的TNC（索引在內存中的copy），同時將更新信息以日志方式記錄在flash中（增加新的bud），等到commit時再更新閃存上的索引樹。日志由log和bud（芽）組成，log記錄日志位置，log包含兩種類型的節點：commit開始節點(UBIFS_CS_NODE)、引用節點(UBIFS_REF_NODE)。commit開始節點記錄commit過程的開始，引用節點記錄bud的數量。日志有多個head，日志LEBs可以不連續。
UBI文件系統日志區是建立在Flash上的，每當文件系統運行時，都會將日志區這個結構映射到內存中，我們稱為TNC樹（也是B+樹）。當我們要對文件系統節點修改、寫數據的時候，先在內存TNC樹做標記，等到commit的時候把修改的數據統一寫到Flash中。TNC樹是日志區在內存中的一個拷貝。內存緊張時TNC可被壓縮
LEB屬性樹區（LEB Properties Tree area，LPT area），跟隨在log area之后，其大小在創建文件系統后確定（比main區indexing樹小的多），LPT使用B+樹（游離樹）結構。LPT area 包含LEB Properties樹，LPT area eraseblock表(ltab)，以及saved LEB numbers表(lsave)。LPT area的大小在文件系統創建時就已經確定了，通過LEB 尺寸和文件系統最大LEB count自動計算出LPT area占用的LEB數目。LPT area類似一個小型的自包含文件系統，它有自己的LEB properties，也就是LEB properties area的LEB properties(ltab)。LPT area有自己的垃圾收集器。LPT area要求不能耗光自己的空間，能夠快速訪問和update，以及算法上的可擴展性。
UBIFS存儲Flash上每個LEB信息（LEB類型：indexing或data，free和dirty space大小），整個flash信息（free和dirty space大小）等，方便UBIFS了解LEB信息。通過此區域可找到可用的LEB，可找到dirty LEB（供GC回收）等。
孤兒區（orphan area），在LPT area和main area之間，使用固定數目的LEBs，一般來說占用一個LEB就夠了，debug時額外占用一個LEB。orphan area記錄已經刪除的文件的索引號（inode number）。orphan area的意義在於刪除過程unclean unmount發生，已經刪除的孤兒inodes必須被刪除，這就要求掃描整個index來查找他們，或者在某處保存一個列表，ubifs就是在orphan area保存這樣一個列表。The orphan area is a fixed number of LEBs situated between the LPT area and the main area
main area，最后一個area，保存文件系統index node和non-index node，存儲實際數據。UBIFS包含幾種類型的non-index節點：file inode, directory entry，extend attribute entry和file data node。UBIFS維護着一棵wandering tree，葉子節點保存着文件信息，它們是文件系統的有效節點。樹的內部節點是index node保存着到children的索引。所以wandering tree可以視為兩個部分，頂部保存樹結構的索引節點（index nodes），底部則是真正文件數據的leaf node（葉子節點）。
8. ubifs文件系統索引節點結構—B+樹（游離樹）
9. 垃圾回收
一個空的LEB總是保留用作GC。
10. Ubifs優點
通過上面了解可推測出ubifs的性能特點。
>>Good scalability
Data structures are trees
Only journal has to be replayed
>> High performance
Write-¬back
Background commit
Read/write is allowed during commit
Multi-¬head journal minimizes amount of GC
TNC makes look¬ups fast
LPT caches make LEB searches fast
>>On¬-the-¬flight compression
>>Power-¬cut tolerance
All updates are out¬-of-¬place
Was extensively tested
>>High reliability
All data is protected by CRC32 checksum
Checksum may be disabled for data
>>Recoverability
All nodes have a header which fully describes the node
The index may be fully re¬constructed from the headers
11. 一個示例
[ 115.987823] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 115.995452] UBIFS: file system size: 8888320 bytes (8680 KiB, 8 MiB, 70 LEBs)
[ 116.003082] UBIFS: journal size: 1650688 bytes (1612 KiB, 1 MiB, 13 LEBs)
[ 116.010742] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 116.016815] UBIFS: default compressor: lzo
[ 116.021087] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 116.026458] UBIFS DBG msg: compiled on: Jul 9 2016 at 17:19:55
[ 116.033355] UBIFS DBG msg: min. I/O unit size: 2048 bytes
[ 116.039062] UBIFS DBG msg: max. write size: 2048 bytes
[ 116.045440] UBIFS DBG msg: LEB size: 126976 bytes (124 KiB)
[ 116.052246] UBIFS DBG msg: data journal heads: 1
[ 116.057159] UBIFS DBG msg: UUID: 4EE5BE06-687A-467A-909B-856187011AA9
[ 116.065460] UBIFS DBG msg: big_lpt 0
[ 116.070343] UBIFS DBG msg: log LEBs: 4 (3 - 6)
[ 116.075988] UBIFS DBG msg: LPT area LEBs: 2 (7 - 8)
[ 116.081634] UBIFS DBG msg: orphan area LEBs: 1 (9 - 9)
[ 116.087249] UBIFS DBG msg: main area LEBs: 70 (10 - 79)
[ 116.095458] UBIFS DBG msg: index LEBs: 2
[ 116.100341] UBIFS DBG msg: total index bytes: 59504 (58 KiB, 0 MiB)
[ 116.107086] UBIFS DBG msg: key hash type: 0
[ 116.115447] UBIFS DBG msg: tree fanout: 8
[ 116.120361] UBIFS DBG msg: reserved GC LEB: 41
[ 116.125335] UBIFS DBG msg: first main LEB: 10
[ 116.135467] UBIFS DBG msg: max. znode size 240
[ 116.140533] UBIFS DBG msg: max. index node size 192
[ 116.145629] UBIFS DBG msg: node sizes: data 48, inode 160, dentry 56
[ 116.153076] UBIFS DBG msg: node sizes: trun 56, sb 4096, master 512
[ 116.160430] UBIFS DBG msg: node sizes: ref 64, cmt. start 32, orph 32
[ 116.167968] UBIFS DBG msg: max. node sizes: data 4144, inode 4256 dentry 312, idx 188
[ 116.176513] UBIFS DBG msg: dead watermark: 2048
[ 116.185455] UBIFS DBG msg: dark watermark: 6144
[ 116.190612] UBIFS DBG msg: LEB overhead: 2656
[ 116.195800] UBIFS DBG msg: max. dark space: 430080 (420 KiB, 0 MiB)
[ 116.202697] UBIFS DBG msg: maximum bud bytes: 1142784 (1116 KiB, 1 MiB)
[ 116.209777] UBIFS DBG msg: BG commit bud bytes: 928512 (906 KiB, 0 MiB)
[ 116.216705] UBIFS DBG msg: current bud bytes 55296 (54 KiB, 0 MiB)
[ 116.223419] UBIFS DBG msg: max. seq. number: 8756
[ 116.228607] UBIFS DBG msg: commit number: 831
[ 54.707519] UBIFS: mounted UBI device 0, volume 1, name "app"
[ 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
[ 55.548645] UBIFS: mounted UBI device 0, volume 2, name "db"
[ 55.554565] UBIFS: file system size: 181448704 bytes (177196 KiB, 173 MiB, 1429 LEBs)
[ 55.562927] UBIFS: journal size: 9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
[ 55.570556] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 55.576629] UBIFS: default compressor: lzo
[ 55.580902] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 55.586273] UBIFS DBG msg: compiled on: Jul 20 2016 at 11:29:21
[ 55.593170] UBIFS DBG msg: min. I/O unit size: 2048 bytes
[ 55.598876] UBIFS DBG msg: max. write size: 2048 bytes
[ 55.604614] UBIFS DBG msg: LEB size: 126976 bytes (124 KiB)
[ 55.611419] UBIFS DBG msg: data journal heads: 1
[ 55.617340] UBIFS DBG msg: UUID: 04BD616F-127C-4396-964E-8510279DEA60
[ 55.625427] UBIFS DBG msg: big_lpt 0
[ 55.630340] UBIFS DBG msg: log LEBs: 5 (3 - 7)
[ 55.635955] UBIFS DBG msg: LPT area LEBs: 2 (8 - 9)
[ 55.641601] UBIFS DBG msg: orphan area LEBs: 1 (10 - 10)
[ 55.647399] UBIFS DBG msg: main area LEBs: 1429 (11 - 1439)
[ 55.653656] UBIFS DBG msg: index LEBs: 1
[ 55.658569] UBIFS DBG msg: total index bytes: 48 (0 KiB, 0 MiB)
[ 55.667358] UBIFS DBG msg: key hash type: 0
[ 55.672241] UBIFS DBG msg: tree fanout: 8
[ 55.677124] UBIFS DBG msg: reserved GC LEB: 12
[ 55.682128] UBIFS DBG msg: first main LEB: 11
[ 55.687133] UBIFS DBG msg: max. znode size 240
[ 55.692199] UBIFS DBG msg: max. index node size 192
[ 55.697296] UBIFS DBG msg: node sizes: data 48, inode 160, dentry 56
[ 55.707336] UBIFS DBG msg: node sizes: trun 56, sb 4096, master 512
[ 55.717346] UBIFS DBG msg: node sizes: ref 64, cmt. start 32, orph 32
[ 55.724884] UBIFS DBG msg: max. node sizes: data 4144, inode 4256 dentry 312, idx 188
[ 55.733398] UBIFS DBG msg: dead watermark: 2048
[ 55.738586] UBIFS DBG msg: dark watermark: 6144
[ 55.743743] UBIFS DBG msg: LEB overhead: 2656
[ 55.748931] UBIFS DBG msg: max. dark space: 8779776 (8574 KiB, 8 MiB)
[ 55.756011] UBIFS DBG msg: maximum bud bytes: 8388608 (8192 KiB, 8 MiB)
[ 55.763092] UBIFS DBG msg: BG commit bud bytes: 6815744 (6656 KiB, 6 MiB)
[ 55.770172] UBIFS DBG msg: current bud bytes 0 (0 KiB, 0 MiB)
[ 55.776428] UBIFS DBG msg: max. seq. number: 8
[ 55.781311] UBIFS DBG msg: commit number: 0
12. more
參考：
1. http://www.linux-mtd.infradead.org/doc/ubifs.html
2. http://www.linux-mtd.infradead.org/doc/ubi.html
3. http://blog.csdn.net/xiaosong521/article/details/7764663
4. A Brief Introduction to the Design of UBIFS