5.1 ubifs文件系統簡介
UBIFS(Unsorted Block Image File System,無排序區塊圖像文件系統)是用於固態存儲設備上，並與LogFS相互競爭，作爲JFFS2的後繼文件系統之一。由於Nand Flash容量的暴漲，JFFS2、Yaffs2等皆無法操控大的Nand Flash空間，IBM、Nokia工程師Thomas Gleixner、Artem Bityutskiy等人2006年發起，致力於開發性能卓越、擴展性高的FLASH專用文件系統，以解決嵌入式環境下以FLASH作爲MTD設備使用時的技術瓶頸。真正開始開發於2007年，並於2008年10月第一次加入穩定版本於Linux核心2.6.27版，在設計與性能上均較優於YAFFS2、JFFS2，更實用於MLC NAND FLASH。因爲UBIFS是直接工作在Raw Flash設備上(如Nandflash)，所以他不能工作在SD卡、U盤這些常用的存儲設備上，目前的安卓手機上絕大部分都是使用的UBIFS文件系統。關於UBIFS的更多信息請參考： http://www.linux-mtd.infradead.org/doc/ubifs.html
傳統的flash文件系統如Jffs2、yaffs2等是工作在MTD設備層之上，而UBIFS則建立在UBI卷層之上，
UBI卷層工作在MTD設備層之上。也可以說，UBIFS涉及三個子系統：
- MTD 子系統，提供對flash芯片Raw的訪問接口。 MTD子系統提供了MTD device的概念，比如/dev/mtdx(字符設備)和/dev/mtdblockX(塊設備)；
2.UBI Subsystem，它工作在MTD設備之上，提供了UBI邏輯卷(類似於Linux服務器上的LVM概念)，對上層屏蔽了一些直接使用MTD設備需要處理的問題，如wear-leveling(磨損平衡算法)和volume management(壞塊管理)功能等；
3.UBIFS文件系統，工作於UBI之上。它提供文件的open、read、write等操作；
作爲新一代文件系統新貴，他具有如下特性：
可擴展性： UBIFS對Flash 尺寸有着很好的擴展性； 也就是說文件系統掛載時間，內存消耗以及I/O速度都不依賴於Flash的大小； UBIFS可以很好的運行在GB級的 flashe設備; 當然UBI本身還是有擴展性的問題，無論如何 UBI/UBIFS都比JFFS2的可擴展性好，如果UBI成爲瓶頸，可以改進UBI而不需改變UBIFS本身；
快速掛載：不像JFFS2，UBIFS在掛載階段不需要掃描整個文件系統，UBIFS mount的時間只是毫秒級，時間不依賴於Flash的大小；然而UBI的初始化時間依賴Flash的大小，因此必須把這個時間考慮在內。
write-back 支持：文件的改變並不是立刻提交到flash media上，而是cache這些修改，直到達到寫入的條件，這減少了I/O的數目因此改善I/O性能和系統性能。回寫本身也是文件系統的標準技術，由於數據沒有立刻寫入flash, 回寫帶來了突然掉電就會存在數據丟失的風險。相反, JFFS2不支持write-back, JFFS2文件系統的所有變化都是立刻同步到flash介質上。同JFFS2的writethrough(立即寫入內存)相比可以顯著的提高文件系統的吞吐量。 容忍不清潔的重啓：UBIFS是日誌文件系統，所以容忍突然關閉和不清潔的重啓。UBIFS會回放日誌並從不切底的重啓中恢復過來。這時掛載時間會有點慢。但由於只是需要重做日誌，而不需要掃描儲存介質，所以性能影響不大。
快速I/O：即使回寫功能被禁能（例如在掛載時加入“-o sync”的參數），UBIFS也表現良好，接近jffs2。在同步I/O方面UBIFS是極難與jffs2相抗爭的。因爲jffs2在flash維護數據索引結構，不需要額外的開銷，而UBIFS需要。然而UBIFS依然是很快，因爲它依靠日誌。它不需要把數據物理地從一個地方移動到另一個地方，僅把有關信息加入文件系統的索引以及爲新日誌挑選一個擦除塊。
快速壓縮：與jffs2相似，UBIFS支持數據壓縮儲存。對於單個文件的儲存，UBIFS可以使能/禁能壓縮功能。
自恢復功能：有數據索引有損壞的情況下，UBIFS可以恢復過來。在UBIFS每一塊信息有描述整個信息的數據頭。在掃描介質的情況下這數據頭信息可以重建。而在FAT文件系統，發生這樣的事件是致命的。
數據的完整性：UBIFS在每次寫入數據時都會對數據進行覈實，以確保數據的完整性。UBIFS不會容忍任何不可用的數據或元數據。然而爲了加快數據的讀寫速度，用戶可以關閉CRC檢查。
5.2 根文件系統鏡像文件製作
我們可以使用mtd-utils源碼編譯出來的mkfs.jffs2工具，將根文件系統樹目錄製作成jffs2根文件系統鏡
像。在開始製作鏡像之前，我們先看看mkfs.jffs2的使用說明：（在前兩篇博客已經講過相關工具的製作）
zhanghang@ubuntu:~/fl2440/linux$ mkfs.ubifs -h
Usage: mkfs.ubifs [OPTIONS] target
Make a UBIFS file system image from an existing directory tree
Examples:
Build file system from directory /opt/img, writting the result in the ubifs.img file
mkfs.ubifs -m 512 -e 128KiB -c 100 -r /opt/img ubifs.img
The same, but writting directly to an UBI volume
mkfs.ubifs -r /opt/img /dev/ubi0_0
Creating an empty UBIFS filesystem on an UBI volume
mkfs.ubifs /dev/ubi0_0
Options:
-r, -d, --root=DIR build file system from directory DIR//指定根文件系統目錄樹的路徑
-m, --min-io-size=SIZE minimum I/O unit size //Nand Flash的最小讀寫單元，一般爲page size。
-e, --leb-size=SIZE logical erase block size//邏輯擦除塊的大小
-c, --max-leb-cnt=COUNT maximum logical erase block count//邏輯擦除塊的個數，與分區大小有關
-o, --output=FILE output to FILE//輸出的根文件系統鏡像文件
-j, --jrn-size=SIZE journal size
-R, --reserved=SIZE how much space should be reserved for the super-user
-x, --compr=TYPE compression type - "lzo", "favor_lzo", "zlib" or
"none" (default: "lzo")
-X, --favor-percent may only be used with favor LZO compression and defines
how many percent better zlib should compress to make
mkfs.ubifs use zlib instead of LZO (default 20%)
-f, --fanout=NUM fanout NUM (default: 8)
-F, --space-fixup file-system free space has to be fixed up on first mount
(requires kernel version 3.0 or greater)
-k, --keyhash=TYPE key hash type - "r5" or "test" (default: "r5")
-p, --orph-lebs=COUNT count of erase blocks for orphans (default: 1)
-D, --devtable=FILE use device table FILE
-U, --squash-uids squash owners making all files owned by root
-l, --log-lebs=COUNT count of erase blocks for the log (used only for
debugging)
-v, --verbose verbose operation
-V, --version display version information
-g, --debug=LEVEL display debug information (0 - none, 1 - statistics,
2 - files, 3 - more details)
-h, --help display this help text
Note, SIZE is specified in bytes, but it may also be specified in Kilobytes,
Megabytes, and Gigabytes if a KiB, MiB, or GiB suffix is used.
If you specify "lzo" or "zlib" compressors, mkfs.ubifs will use this compressor
for all data. The "none" disables any data compression. The "favor_lzo" is not
really a separate compressor. It is just a method of combining "lzo" and "zlib"
compressors. Namely, mkfs.ubifs tries to compress data with both "lzo" and "zlib"
compressors, then it compares which compressor is better. If "zlib" compresses 20
or more percent better than "lzo", mkfs.ubifs chooses "lzo", otherwise it chooses
"zlib". The "--favor-percent" may specify arbitrary threshold instead of the
default 20%.
The -F parameter is used to set the "fix up free space" flag in the superblock,
which forces UBIFS to "fixup" all the free space which it is going to use. This
option is useful to work-around the problem of double free space programming: if the
flasher program which flashes the UBI image is unable to skip NAND pages containing
only 0xFF bytes, the effect is that some NAND pages are written to twice - first time
when flashing the image and the second time when UBIFS is mounted and writes useful
data there. A proper UBI-aware flasher should skip such NAND pages, though. Note, this
flag may make the first mount very slow, because the "free space fixup" procedure
takes time. This feature is supported by the Linux kernel starting from version 3.0.
zhanghang@ubuntu:~/fl2440/linux$ mkfs.ubifs -x lzo -m 2048 -e 129024 -c 300 -r ./rootfs -o rootfs-ubifs.img
-x lzo 指定使用lzo壓縮方法，默認是lzo，還支持zlib，zlib壓縮率高些，但是lzo壓縮解壓速度快 。
-m 2048 Nand Flash的最小讀寫單元，一般爲page size，K9F2G08的頁大小爲2048字節。
-r ./rootfs 指定根文件系統目錄樹的路徑
-o rootfs-ubifs.img 指定製作出的根文件系統鏡像文件名
-e 129024 指定LEB（Logical Erase Block，邏輯擦除塊）大小。大家知道
Nandflash讀寫單位爲頁，擦除單位爲塊，一個設備有多個塊，一個塊有多個頁，K9F2G08Nandflash一個塊是64個頁，而一個頁大小爲2048字節。這樣一個PEB（Physical EraseblockSize，物理擦除塊）大小就是204864=131072，-e的算法是物理擦除塊大小-1頁大小，這裏就是131072-12048=129024
-c 300 指定該分區最大邏輯擦除塊數量，該值隨着根文件系統分區的大小和該分區的壞塊數調整。該值很重要，不能大也不能小，太小也要大於image大小，太大mount有問題。計算起點是分區的物理塊數量，比如40MiB的mtd分區，物理擦除塊數量是401024*1024/2048/64 = 320個，需要減去2個volume table的塊，1個wear-leveling塊，1個atomic LEB change塊，以及一些壞塊處理的保留塊。因爲一個分區上有多少個壞塊是隨機的，一般做法是做一個壞塊容忍數，比如16個，不要擔心這個會浪費空間，ubinize的autoresize選項就是解決這個問題的。在這裏我們最終的邏輯擦除塊個數計算公式爲： 320-2(volume table)-1(Wear-leveling)-1(atomic LEB change)-16(壞塊容量數)=300
UBIFS是建立在UBI之上的文件系統，因此使用mkfs.ubifs製作的根文件系統鏡像不能直接使用u-boot
的nand write命令燒錄，而需要在u-boot下使用ubi命令在根文件系統所在分區建立ubi卷之後才能燒
錄。但這種燒錄方式比較麻煩，這時我們可以使用另外ubinize命令對rootfs-ubifs.img文件進行處理後
就可以在u-boot上直接用nand write命令寫入到根文件系統分區了。該命令的使用方法如下：
zhanghang@ubuntu:~/fl2440/linux$ ubinize -h
...//自己看。。我不寫了哈哈
首先我們需要創建ubinize的配置文件，然後再使用ubinize命令對image進行處理：
zhanghang@ubuntu:~/fl2440/linux$ vim ubinize.ini
[ubifs-volume]
mode=ubi
image=rootfs-ubifs.img
vol_id=0
vol_size=38707200
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
vol_alignment=1
配置文件說明：
mode=ubi
image=rootfs-ubifs.img 指定mkfs.ubifs製作生成的根文件系統鏡像文件路徑;
vol_id=0 指定根文件系統樹的卷標爲0，u-boot的bootargs參數需要根據它來設置；
vol_size=38707200 指定該UBI邏輯卷的大小，該值計算公式一般爲 邏輯擦除塊大小邏輯擦除塊個數=129024300=38707200。該值一般不用寫，默認值是image大小。寫了這個作用是幫助檢查image是否超過了分區限制，製作時候就提示，否則mount會出錯。邏輯擦除塊個數的值是經過計算的最大值了，不過autoresize參數會自適應大小，不會浪費空間的，後面Linux系統內核啓動過程中可以看到這個現象。
vol_type=dynamic
vol_name=rootfs 指定UBI卷的名稱，u-boot的bootargs參數需要根據它來設置；
vol_flags=autoresize UBI Subsystem在系統啓動時自動調整邏輯擦除塊的個數
vol_alignment=1
zhanghang@ubuntu:~/fl2440/linux$ ubinize -o rootfs-ubifs.bin -m 2048 -p 131072 -s 512 -O 512 ubinize.ini
-o rootfs-ubifs.bin 指定ubinize處理後輸出的image文件名，該文件可以由u-boot的nand write命令直接燒錄
-m 2048 指定minimum input/output unit大小，爲nandflash的頁大小。
-p 131072 指定物理擦除塊大小: 64 Page*2048 Byte/Page = 131072
-s 512 指定sub-page-size大小，頁大小爲2048字節的nandflash對應值爲512；對於其他的Nandflash可以在Linux內核跑起來後掛載ubifs後查看該值
-O 512 指定vid-hdr-offset值，默認爲sub-page-size的值，可以省略不用。
zhanghang@ubuntu:~/fl2440/linux$ du -h rootfs-ubifs.bin
8.5M rootfs-ubifs.bin
經過 ubinize 命令處理過後的根文件系統鏡像文件rootfs-ubifs.bin 就可以直接在u-boot下使用nand write
命令燒錄到相應的根文件系統分區上去了。
5.3 內核配置和編譯
Linux內核需要重新make menuconfig配置做如下修改，編譯並生成的Linux內核鏡像文件才能支持
UBIFS文件系統。
在上篇博客製作jffs2文件系統基礎上修改：
zhanghang@ubuntu:~/fl2440/linux$ cd linux-3.0/
zhanghang@ubuntu:~/fl2440/linux/linux-3.0$ export TERM=vt100
zhanghang@ubuntu:~/fl2440/linux/linux-3.0$ make menuconfig
General setup --->
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support 一定要取消initamfs，否則內核找到initramfs根文件系統的話就直接使用他啓動了。
Device Drivers --->
<*> Memory Technology Device (MTD) support --->
< > RedBoot partition table parsing
< > FTL (Flash Translation Layer) support
< > NFTL (NAND Flash Translation Layer) support
<*> Enable UBI - Unsorted block images ---> 因爲UBIFS文件系統建立在UBI一層上，所以只有這裏選擇了UBI之後，下面的文件系統裏纔會有UBIFS的選項
(4096) UBI wear-leveling threshold (NEW)
(1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)
< > MTD devices emulation driver (gluebi) (NEW)
[ ] UBI debugging (NEW)
File systems --->
[*] Miscellaneous filesystems --->
<*> UBIFS file system support 選擇支持UBIFS文件系統
[*] Extended attributes support
[*] Advanced compression options
[*] LZO compression support (NEW)
[*] ZLIB compression support (NEW)
[ ] Enable debugging support (NEW)
重新編譯生成Linux內核uImage鏡像文件：
zhanghang@ubuntu:~/fl2440/linux/linux-3.0$ ./build.sh
...
CC net/ipv4/esp4.mod.o
LD [M] net/ipv4/esp4.ko
CC net/ipv6/ah6.mod.o
LD [M] net/ipv6/ah6.ko
CC net/ipv6/esp6.mod.o
LD [M] net/ipv6/esp6.ko
Image Name: Linux Kernel
Created: Mon Apr 29 06:01:23 2019
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2544680 Bytes = 2485.04 kB = 2.43 MB
Load Address: 30008000
Entry Point: 30008040
zhanghang@ubuntu:~/fl2440/linux/linux-3.0$ du -h linuxrom-s3c2440.bin
2.5M linuxrom-s3c2440.bin
將linuxrom-s3c2440.bin和相應的根文件燒錄到開發板，並配置：
[fl2440@lingyun]# set bootcmd 'nand read 30008000 100000 400000; bootm 30008000'
[fl2440@lingyun]# set bootargs 'console=tty0 console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs mem=64M noinitrd rw loglevel=7'
[fl2440@lingyun]# save
ubi.mtd=2 指定UBI卷建立在mtd2上，該值應該與u-boot燒錄位置、Linux內核分區保持一致；如果錯誤則Linux內核會因找不到根文件系統而啓動失敗；
root=ubi0:rootfs 指定根文件系統所在位置：在製作UBIFS的過程中，我們通過ubinize命令對文件系統鏡像進行處理時，其配置文件中的vol_id指定爲0，vol_name指定爲rootfs；
rootfstype=jffs2 指定根文件系統類型爲jffs2，如果該參數錯誤則內核啓動失敗；
登錄開發板：
usb 1-1: device not accepting address 4, error -62
usb 1-1: new full speed USB device number 5 using s3c2410-ohci
usb 1-1: device not accepting address 5, error -62
hub 1-0:1.0: unable to enumerate USB device on port 1
dm9000 dm9000: eth0: link down
Default Logon Username: root Password: 123456
LingYunFL2440 login: dm9000 dm9000: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
root
Password:
~ >: ls
apps dev init mnt sbin usr
bin etc lib proc sys var
data info linuxrc root tmp
~ >: mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
proc on /proc type proc (rw,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
因爲UBIFS是建立在Nandflash上的根文件系統，在該文件系統路徑下所有的文件修改掉電後都不會丟
失。所以我們在根路徑下創建haha文件後，把開發板重啓發現該文件還存在
5.6 普通分區ubifs掛載
UBIFS除了可以製作成根文件系統使用以外，我們也可以在系統成功啓動後，將其他分區以jffs2文件系統類型掛載使用。
UBIFS文件系統掛載
這裏我們以 mtdblock3 爲例將其以ubifs文件系統格式掛載到 /apps 掛載點上：
~ >: cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "mtdblock0 u-boot 1MB"
mtd1: 00f00000 00020000 "mtdblock1 kernel 15MB"
mtd2: 02800000 00020000 "mtdblock2 rootfs 40MB"
mtd3: 05000000 00020000 "mtdblock3 apps 80MB"
mtd4: 05000000 00020000 "mtdblock4 data 80MB"
mtd5: 02800000 00020000 "mtdblock5 backup 40MB"
~ >: flash_eraseall /dev/mtd3
Erasing 128 Kibyte @ 5000000 - 100% complete.
~ >: ls /dev/ubi*
/dev/ubi0 /dev/ubi0_0 /dev/ubi_ctrl
~ >: ubiattach
BusyBox v1.27.1 (2019-04-29 05:27:21 PDT) multi-call binary.
Usage: ubiattach -m MTD_NUM [-d UBI_NUM] [-O VID_HDR_OFF] UBI_CTRL_DEV
Attach MTD device to UBI
-m MTD_NUM MTD device number to attach
-d UBI_NUM UBI device number to assign
-O VID_HDR_OFF VID header offset
~ >: ubiattach -m 3 -d 3 /dev/ubi_ctrl
UBI: attaching mtd3 to ubi3
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: empty MTD device detected
UBI: max. sequence number: 0
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd3 to ubi3
UBI: MTD device name: "mtdblock3 apps 80MB"
UBI: MTD device size: 80 MiB
UBI: number of good PEBs: 640
UBI: number of bad PEBs: 0
UBI: number of corrupted PEBs: 0
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: 630
UBI: total number of reserved PEBs: 10
UBI: number of PEBs reserved for bad PEB handling: 6
UBI: max/mean erase counter: 0/0
UBI: image sequence number: -1643353706
UBI: background thread "ubi_bgt3d" started, PID 927
~ >: ls /dev/ubi*
/dev/ubi0 /dev/ubi0_0 /dev/ubi3 /dev/ubi_ctrl
~ >: ubimkvol -m -n 0 -N apps /dev/ubi3
~ >: mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
proc on /proc type proc (rw,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
~ >: ls /dev/ubi*
/dev/ubi0 /dev/ubi0_0 /dev/ubi3 /dev/ubi3_0 /dev/ubi_ctrl
~ >: mount -t ubifs -o sync,noatime,rw ubi3:apps /apps/
UBIFS: default file-system created
UBIFS: mounted UBI device 3, volume 0, name "apps"
UBIFS: file system size: 80123904 bytes (78246 KiB, 76 MiB, 621 LEBs)
UBIFS: journal size: 3999744 bytes (3906 KiB, 3 MiB, 31 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root: 3784449 bytes (3695 KiB)
~ >: mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
proc on /proc type proc (rw,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
ubi3:apps on /apps type ubifs (rw,sync,noatime)
關鍵命令：
~ >: flash_eraseall /dev/mtd3 使用flash_eraseall命令將mtd3所在分區全部擦除
~ >: ls /dev/ubi* 列出當前存在的ubi設備
~ >: ubiattach -m 3 -d 3 /dev/ubi_ctrl 在mtd3上關聯ubi3
~ >:ubimkvol -m -n 0 -N apps /dev/ubi3 在ubi3上建立UBI卷
~ >: mount -t ubifs -o sync,noatime,rw ubi3:apps /apps/ 掛載ubi3(即mtdblock3)到
/apps掛載點上
UBIFS文件系統卸載及重新掛載測試
~ >: umount /apps/ 卸載ubifs
UBIFS: un-mount UBI device 3, volume 0
~ >: ubidetach -d 3 /dev/ubi_ctrl 解除ubi和mtd之間的關聯
UBI: mtd3 is detached from ubi3
~ >: ls /dev/ubi* 查看UBI設備，現在ubi3相關的設備都消除
/dev/ubi0 /dev/ubi0_0 /dev/ubi_ctrl
我們再次關聯ubi3到mtd3下的時候，因爲之前已經在該分區上建立過UBI卷，所以再次建立UBI卷的話
將會出錯。這也意味着，如果之前已經用ubimkvol建立UBI卷的分區再次掛載時不需要在執行該命
令，也即ubimkvol針對一個分區只能做一次，除非使用flash_eraseall重新格式化。
~ >: ubiattach -m 3 -d 3 /dev/ubi_ctrl 之前已經建立了卷，現在ubiattach之後就會存在ubi卷設
備ubi3_0。
~ >: ls /dev/ubi*
/dev/ubi0 /dev/ubi0_0 /dev/ubi3 /dev/ubi3_0 /dev/ubi_ctrl
~ >: ubimkvol -m -n 0 -N apps /dev/ubi3
ubimkvol: UBI_IOCMKVOL: Invalid argument
系統重啓後，並不會自動掛載/dev/mtdblock3到/apps路徑下，這時我們還是需要用命令手動掛載才能
看到/app路徑下的haha文件存在。
這時我們可以寫一個shell腳本，使系統啓動時直接掛載mtdblock3到apps下:
~ >: cd etc/init.d/
/etc/init.d >: vim S_mount_ubifs_mtd3_apps
#bin/sh
ubiattach -m 3 -d 3 /dev/ubi_ctrl
ubimkvol -m -n 0 -N apps /dev/ubi3
mount -t ubifs -o sync,noatime,rw ubi3:apps /apps/
/etc/init.d >: chmod a+x S_mount_ubifs_mtd3_apps
這樣，每次系統啓動就會將mtdblock3掛在在apps下。