ubifs根文件系统制作

版权声明:转载请附带原博主的网址 https://blog.csdn.net/qq_43260665/article/details/89684899

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涉及三个子系统:

  1. 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的write
through(立即写入内存)相比可以显著的提高文件系统的吞吐量。
容忍不清洁的重启: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读写单位为页,擦除单位为块,一个设备有多个块,一个块有多个页,K9F2G08
Nandflash一个块是64个页,而一个页大小为2048字节。这样一个PEB(Physical Eraseblock
Size,物理擦除块)大小就是204864=131072,-e的算法是物理擦除块大小-1页大小,这里
就是131072-12048=129024
-c 300 指定该分区最大逻辑擦除块数量,该值随着根文件系统分区的大小和
该分区的坏块数调整。该值很重要,不能大也不能小,太小也要大于image大小,太大mount有
问题。计算起点是分区的物理块数量,比如40MiB的mtd分区,物理擦除块数量是
40
1024*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逻辑卷的大小,该值计算公式一般为 逻辑擦除块大小逻辑擦除块个数
=129024
300=38707200。该值一般不用写,默认值是image大小。写了这个作用是帮助检查image是否超过了
分区限制,制作时候就提示,否则mount会出错。逻辑擦除块个数的值是经过计算的最大值了,不过autoresize
参数会自适应大小,不会浪费空间的,后面Linux系统内核启动过程中可以看到这个现象。
vol_type=dynamic
vol_name=rootfs 指定UBI卷的名称,u-boot的bootargs参数需要根据它来设置;
vol_flags=autoresize UBI Subsystem在系统启动时自动调整逻辑擦除块的个数
vol_alignment=1
[guowenxue@centos6_master 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$ 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下。

猜你喜欢

转载自blog.csdn.net/qq_43260665/article/details/89684899