[系统运维]【NAND文件系统】UBIFS介绍

UBIFS

UBIFS 是诺基亚工程师在塞格德大学的帮助下开发的一种新的闪存文件系统。 在某种程度上，UBIFS 可以被视为 JFFS2 文件系统的下一代。

UBIFS工作在UBI卷之上，不能在MTD设备之上运行，也不能在block设备上运行。

UBIFS需要如下3个子系统参与：

• MTD 子系统，它提供了访问闪存芯片的统一接口。 MTD 提供了 MTD 设备的概念（例如，/dev/mtd0），它基本上代表原始闪存；
• UBI 子系统，这是一个用于闪存设备的磨损均衡和卷管理系统； UBI 在MTD设备之上工作并提供UBI卷的概念； UBI 卷是比 MTD 设备更高级别的实体，它们没有 MTD 设备存在的许多令人不快的问题（例如，磨损和坏块）； 浏览此处获取更多信息;
• UBIFS 文件系统，它在 UBI卷之上工作。

以下是一些UBIFS特性：

可扩展性

UBIFS 在闪存大小方面可以很好地扩展；即挂载时间、内存消耗和 I/O 速度不依赖于 flash 大小（目前内存消耗不是 100% 正确，但依赖性不是很强，后续可能会修复）； UBIFS（不是 UBI）应该适用于数百 GiB 闪存；但是，UBIFS 依赖于具有可扩展性限制的 UBI；尽管如此，UBI/UBIFS 堆栈的可伸缩性比 JFFS2 好得多，如果 UBI 成为瓶颈，始终可以在不更改 UBIFS 的情况下实现UBI2

UBIFS 使用的所有数据结构都是树，因此它在闪存大小方面呈对数缩放。 然而，UBI 是线性扩展的，这使得整个UBI/UBIFS堆栈的可扩展性是线性的。 但 UBIFS 的作者相信创建对数可扩展的UBI2并改善这种情况是可能的。 当前的 UBI 对于2-16GiB 原始闪存应该没问题，具体取决于I/O速度和要求。

请注意，尽管 UBI 可扩展性是线性的，但无论如何它的可扩展性都比 JFFS2 好得多，JFFS2 最初是为小型 ~32MiB NOR 闪存设计的。 JFFS2 在“文件系统级别”上存在可伸缩性问题，而 UBI/UBIFS 堆栈仅在较低的“原始闪存级别”上存在可伸缩性问题

快速挂载

与 JFFS2 不同，UBIFS 在挂载时不必扫描整个flash，UBIFS 挂载只需要几毫秒，并且与闪存大小无关；但是，UBI 初始化时间取决于闪存大小并且必须考虑在内

回写支持

与JFFS2相比，这显着改善了许多工作负载中文件系统的吞吐量。

UBIFS 支持回写，这意味着文件更改不会立即写入FLash，而是缓存并稍后在绝对必要时写入Flash。这有助于大大减少 I/O 的数量，从而获得更好的性能。回写缓存是大多数文件系统（如 ext3 或 XFS）使用的标准技术。

相比之下，JFFS2 不支持回写，所有 JFFS2文件系统更改都同步到闪存中。嗯，这并不完全正确，JFFS2 确实有一个 NAND 页面大小的小缓冲区（如果底层闪存是NAND）。这个缓冲区包含最后写入的数据，一旦满了就会被刷新。但是，由于缓存的数据量非常小，JFFS2 非常接近同步文件系统。

回写支持要求应用程序程序员特别注意及时同步重要文件。否则文件可能会在断电的情况下损坏或消失，这在许多嵌入式设备中经常发生。让我们看一下 Linux 手册页：

$ man 2 write

A successful return from write() does not make any guarantee that data has been committed to disk.  On  some  filesystems,
including  NFS,  it  does  not  even guarantee that space has successfully been reserved for the data.  In this case, some
errors might be delayed until a future write(2), fsync(2), or even close(2).  The only way to be sure is to call  fsync(2)
after you are done writing all your data.

这对于 UBIFS 来说是正确的。 JFFS2 以及任何其他 Linux 文件系统也是如此。

然而，一些（也许不是很好）用户空间程序员没有考虑回写。 他们没有仔细阅读手册页。 当在运行 JFFS2 的嵌入式系统中使用此类应用程序时，它们可以正常工作，因为 JFFS2 几乎是同步的。 当然，这些应用程序有问题，但它们似乎与 JFFS2 一起工作得很好。 但是当使用 UBIFS 时，错误就会出现。 如果您从 JFFS2 切换到 UBIFS，请小心检查/测试您的应用程序的断电容限。 以下是有用的提示和建议的列表。

• 如果要切换到同步模式，挂载UBIFS时使用-o sync选项；但是，文件系统性能会下降 - 请小心。还要记住，以同步模式挂载的 UBIFS 提供的保证少于 JFFS2 - 请参阅本节了解详细信息。

• 始终牢记手册页中的上述声明，并为您更改的所有重要文件运行 fsync()；当然，不需要同步“丢弃”的临时文件；只需考虑文件数据的重要性并做出决定；不要不必要地使用 fsync()，因为这会影响性能。

• 如果你想更准确，你可以使用 fdatasync()，在这种情况下，只会刷新数据更改，而不是 inode 元数据更改（例如，“mtime”或权限）；如果经常进行同步（例如，在循环中），这可能比使用 fsync() 更优化；否则就坚持使用 fsync()。

• 在 shell 中，可以使用sync命令，但它会同步整个文件系统，这可能不是最佳的；并且有一个类似的 libc sync() 函数。

• 您可以使用 open() 调用的 O_SYNC 标志；这将确保所有数据（但不是元数据）更改在 write() 操作返回之前写入Flash；但总的来说，最好使用 fsync()，因为 O_SYNC 使每次写入都是同步的，而 fsync() 允许累积许多写入并一次同步它们。

• 可以通过设置“sync”inode标志使某些inode默认同步；在 shell 中，可以使用 chattr +S 命令；在 C 程序中，使用 FS_IOC_SETFLAGS ioctl 命令；注意，mkfs.ubifs 工具会检查原始 FS 树中的“sync”标志，因此原始 FS 树中的同步文件将在生成的 UBIFS 映像中同步。

上述项目适用于任何 Linux 文件系统，包括 JFFS2。

可以为目录调用 fsync() - 它同步目录inode元数据。也可以为目录设置“同步”标志，以使目录inode 同步。但是该标志是继承的，这意味着该目录的所有新子级也将具有该标志。该目录的新文件和子目录也将是同步的，它们的子目录等等。如果需要创建一个完整的同步文件和目录的子树，或者使某个目录的所有新子目录默认同步（例如，/etc），此功能非常有用。

对目录的 fdatasync() 调用在 UBIFS 中是“无操作”，并且所有更改目录条目的 UBIFS 操作都是同步的。但是，您不应该为了可移植性而假设这一点（例如，这不适用于 ext2）。同样，“dirsync”inode 标志在 UBIFS 中无效。

上面提到的函数适用于文件描述符，而不适用于流 (FILE *)。要同步流，您应该首先使用 fileno() libc 函数获取其文件描述符，然后使用 fflush() 刷新流，然后使用 fsync() 或 fdatasync() 同步文件。您可以使用其他同步方法，但请记住在同步文件之前刷新流。 fflush() 函数刷新 libc 级缓冲区，而 sync()、fsync() 等刷新内核级缓冲区。

容忍不干净的重启

UBIFS 是一个日志文件系统，它可以容忍突然的崩溃和不干净的重启； UBIFS 只是重播日志并从不干净的重启中恢复；在这种情况下，挂载时间会稍微慢一些，因为需要重播日志，但是 UBIFS 不需要扫描整个媒体，因此挂载 UBIFS 需要几分之一秒；

快速 I/O

即使禁用回写（例如，如果使用“-o sync”挂载选项挂载 UBIFS）UBIFS 显示出接近 JFFS2 性能的良好性能；请记住，在同步 I/O 方面与 JFFS2 竞争非常困难，因为 JFFS2 不在闪存上维护索引数据结构，因此它没有维护开销，而 UBIFS 有；但是 UBIFS 仍然很快，因为 UBIFS 提交日志的方式——它不会将数据从一个地方物理移动到另一个地方，而是只是将相应的信息添加到文件系统索引，并为新日志选择不同的擦除块（UBIFS有一种不断改变位置的“流浪”日志）；

动态压缩

数据以压缩形式存储在Flash上，与未压缩数据相比，可以将更多的数据放入Flash；这与 JFFS2 非常相似； UBIFS 还允许在每个 inode 的基础上打开/关闭压缩，非常灵活；例如，可以默认关闭压缩并仅对某些应该压缩良好的文件启用它；或者默认情况下可以打开压缩，但对于多媒体文件等所谓的不可压缩数据禁用它；目 UBIFS仅支持 zlib和LZO两种压缩算法；

UBIFS 支持on-the-flight 压缩，这意味着它在将数据写入闪存介质之前对其进行压缩，在读取数据之前对其进行解压缩，这对用户来说是绝对透明的。 UBIFS 仅压缩常规文件数据。目录、设备节点等未压缩。元数据和索引信息也没有被压缩。

目前 UBIFS 支持 LZO 和 zlib 压缩算法。 Zlib 提供了更好的压缩比，但 LZO 在压缩和解压方面都更快。 LZO 是 UBIFS 和 mkfs.ubifs 实用程序的默认压缩算法。当然，您可以使用“-x none”mkfs.ubifs 选项完全禁用UBIFS压缩。

UBIFS 将所有数据拆分为 4KiB 块并独立压缩每个块。这不是最优的，因为更大的数据块会更好地压缩，但这仍然提供了明显的闪存空间经济性。例如，ARM 平台的真实根文件系统映像使用 LZO 压缩会缩小约 40%，使用 zlib 压缩会缩小约 50%。这意味着您可以将 300MiB 的 rootfs 映像放入 256MiB 的 UBI 卷中，并且仍然有大约 100MiB 的可用空间。但是，根据文件系统的内容，这些数字可能会有所不同。例如，如果您的文件系统主要包含 mp3 文件，UBIFS 将无法有效地压缩它们，因为 mp3 文件已经被压缩。

在 UBIFS 中，可以通过设置或清除每个inode 的压缩标志来单独启用或禁用压缩。注意，目录的压缩标志是继承的，也就是说，在创建文件和子目录时，会继承父目录的压缩标志。

也可以在某种程度上组合LZO和 zlib 压缩算法。

可恢复性

如果索引信息损坏，UBIFS也可能完全恢复； UBIFS中的每条信息都有一个描述这条信息的头，可以通过扫描Flash质来完全重建文件系统索引；这与 JFFS2 非常相似；为了更清晰的描述这一点，假设您已经清除了FAT文件系统上的 FAT表；对于 FAT FS，这将是致命的；但是如果你同样清除UBIFS 索引，你仍然可以重新构建它，尽管需要一个特殊的用户空间工具来做到这一点（虽然这个工具目前还没有实现）；

完整性

UBIFS（以及 UBI）校验它写入FLASH的所有内容以保证数据完整性，UBIFS 不会忽视数据或元数据损坏（JFFS2 也是如此）；默认情况下，UBIFS 从FLASH读取时只检查元数据 CRC，而不检查数据 CRC；但是，您可以使用 UBIFS 挂载选项之一强制对数据进行 CRC 检查

意外断电容忍性

UBI和 UBIFS都可以容忍断电，并且它们的设计考虑了这个属性。UBIFS具有模拟电源故障的内部调试基础设施，作者将其用于广泛的测试。它通过电源故障仿真进行了长时间的测试。仿真的优点是即使在不经常发生的情况下也能仿真电源故障。例如，当主节点更新，或者日志发生变化时。在现实生活中，那些经常意外断电的系统非常少。另外，还有一个名为 integck 的强大的用户空间测试程序，它执行大量随机I/O操作并在重新挂载后检查FS的完整性。该测试还可以处理模拟断电并检查 FS 完整性。

source code

UBIFS源码仓库：

http://git.infradead.org/ubifs-2.6.git

git 树有 master 和 linux-next 分支。

• master 分支包含最新的东西，这些东西通常是不完整的、有缺陷的或没有经过很好的测试。这个分支可能会不时重新建立。
• linux-next 分支包含稳定的 UBIFS 更新和修复。

User-space tools

目前只有一个UBIFS用户空间工具mkfs.ubifs，它可以创建 UBIFS 映像。 该工具包含在mtd-utils 中。

ubuntu 安装mtd-utils

sudo apt install mtd-utils

• mkfs.ubifs工具：

Usage： mkfs.ubifs [OPTIONS] target

SIZE 以字节为单位指定，但也可以以KiB(千字节)、MiB(兆字节)和GiB(千兆字节)为单位指定。

-x选项选择要用于文件系统的压缩算法. UBIFS 目前支持 zlib 和 LZO（默认）。通常，zlib 压缩得更好，但压缩和解压都比较慢。 所以这是空间节省和速度之间的权衡。 最好的办法是尝试两者并选择更适合您的一种。 也可以关闭压缩。

-c 选项指定文件系统大小。但不是指定确切的文件系统大小，此选项定义最大文件系统大小（更严格地说，最多使用的UBI卷大小）。 例如，如果设置--max-leb-cnt=200 ，则可以将生成的镜像写入小于200 LEBS的UBI卷并挂载它。 但是如果将镜像写入大于200 LEBs的UBI 卷中，文件系统无论如何都只会占用前200个LEB，而剩余的卷将被浪费掉。

请注意， --max-leb-cnt 选项不会影响生成的镜像文件的大小，镜像文件的大小仅取决于文件系统中的数据量。 mkfs.ubifs 只是将 --max-leb-cnt 值写入文件系统超级块。

-F选项会导致mkfs.ubifs在超级块中设置一个特殊标志(fixup)，从而在第一次挂载文件系统时在内核中触发"free space fixup过程。这个修复过程包括在UBIFS文件系统中查找所有空页并重新擦除它们。这确保了包含所有0xFF数据的NAND页面被完全删除，从而从它们的OOB区域删除任何有问题的非0xFF数据。

当然，不可能重新擦除单个nand page，整个peb都会被擦除。ubifs通过读取LEB的有用(非0xFF)内容，然后调用atomic LEB change操作来执行这个过程。显然，这意味着ubifs必须读写大量的leb，这需要时间。但是这种情况只发生一次，然后free space fixup过程会取消fixupubifs超级块标志。

-R选项用于为超级用户保留一些空间。这意味着当普通用户的文件系统已满时，超级用户仍然有一些空间可以使用。 像 ext2 这样的文件系统也有类似的特性。默认情况下，只有 root 可以使用保留空间。
注意，UBIFS 会在挂载文件系统时打印保留空间的数量。 请参阅系统日志中的UBIFS消息。

还有其他高级文件系统和UBI特性可以通过工具的各种选项进行更改。 仅当您了解它们的作用时才使用它们。

UBIFS使用示例

使能UBIFS

由于UBIFS在UBI之上运行，必须先启用 UBI。

在Linux配置菜单中，选择如下配置使能UBIFS。

"File systems" 
    -> "Miscellaneous filesystems"
        -> "UBIFS file system support"

创建UBIFS镜像

由于 UBIFS 工作在UBI之上，而UBI工作在MTD设备(基本上可以表示raw flash设备)之上。 这意味着，如果需要创建一个需要烧写到raw flash的镜像，首先创建一个UBIFS镜像，然后是UBI镜像。 换句话说，该过程有两个步骤

• mkfs.ubifs 创建 UBIFS 镜像
• ubinize 从 UBIFS 镜像中创建UBI镜像。

UBI 和 UBIFS 镜像取决于将要使用的闪存的参数。即在创建镜像之前，您必须了解Flash 的以下特性：

• MTD分区大小；
• FLASH物理擦除块大小；
• 最小FLASH输入/输出单元尺寸；
• 对于NAND FLASH-sub-page大小；
• 逻辑擦除块大小

如果您运行 Linux 内核版本 2.6.30 或更高版本，或者您向后移植了 MTD sysfs 支持，那么您可以通过运行带有 -u 参数的 mtdinfo工具找到所有这些参数。

# mtdinfo -u /dev/mtd6

......
Eraseblock size:                262144 bytes, 256.0 KiB
Amount of eraseblocks:          256 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 4096 bytes
Sub-page size:                  4096 bytes
OOB size:                       64 bytes
......
Default UBI VID header offset:  4096
Default UBI data offset:        8192
Default UBI LEB size:           253952 bytes, 248.0 KiB
Maximum UBI volumes count:      128

镜像制作

• 制作ubifs镜像

$ mkfs.ubifs -m 4KiB -e 248KiB -c 1024  --space-fixup  --compr=lzo  --squash-uids -r ubifs_test -o ubifs.image

mkfs.ubifs的参数说明：

• -m 最小编程单位为4KB，对应nandflash一个page大小
• -e 逻辑擦除块大小为 248KB
• -c 镜像最大值为1024个逻辑擦除块
• –compr 压缩算法lzo
• -r 根据ubifs_test目录构建文件系统
• -o 输出文件ubifs.image

执行完成后，ubifs_test目录所有的内容都会被打包进文件系统，最终生成镜像ubifs.image。

ubifs.image是ubifs镜像，可以通过ubiupdatevol工具直接写入ubi卷，但是不能直接写入raw flash。
因为UBIFS是运行在UBI卷上，而不是RAW FLASH上的。

此外，也可以在目标系统上构建镜像并将其直接写入UBI卷 - 只需将mkfs.ubifs的输出指向卷字符设备即可 (这里的mkfs.ubifs是运行在目标系统上的)

• 制作ubi镜像

$ cat ubinize.cfg 
[my_ubifs]
mode=ubi
vol_id=0
vol_type=dynamic
vol_name=my_ubifs
vol_flags=autoresize
image=ubifs.image

$ ubinize -m 4KiB -p 256KiB ubinize.cfg -o ubi.image

ubinize.cfg 参数说明：

• mode ubi
• vol_type 动态卷类型
• vol_name 卷名字my_ubifs
• vol_size 指定卷大小(静态卷需要指定此属性)
• vol_flags 这个卷的大小将在UBI第一次运行时被修改
• image 卷的内容取自ubifs.image文件

ubinize的参数说明：

• -m 最小编程单位为4KB，对应nandflash一个page大小
• -p 物理擦擦块为256KB，对应NANDFALSH一个block大小
• ubinize.cfg ubi镜像配置文件
• -o 输出文件ubi.image

ubi.image是ubi镜像，可以直接写入mtd设备(raw flash).
也可以通过ubiformat工具写入mtd设备。

UBIFS挂载

以下是 UBIFS 特定的挂载选项。

• chk_data_crc (默认) - 检查数据 CRC-32 校验和；
• no_chk_data_crc - 不检查数据 CRC-32 校验和；
• bulk_read - 启用批量读取，请参见此处；
• no_bulk_read（默认）- 不批量读取。

例子：

# 将UBIFS 文件系统挂载到 /mnt/ubifs 并禁用数据CRC检查
$ mount -o no_chk_data_crc /dev/ubi0_0 /mnt/ubifs

此外，UBIFS 支持标准同步挂载选项(sync)，可用于禁用UBIFS回写和写缓冲区缓存并使其完全同步。 注意，UBIFS 不支持atime，所以atime 挂载选项无效。

下面介绍如何挂载上一节制作的ubifs。

1.首先可以使用ubiformat工具将ubi镜像写入FLASH,使用ubiformat工具的好处是它可以保留擦除计数器。

$ ubiformat /dev/mtd4 -y -f ubi.image

2.写入完成后，首先需要进行attach

$ ubiattach -p /dev/mtd4  

3.attach后会自动分配ubi设备ID,使用ubinfo -a 列出所有UBI设备信息，刚刚新增的UBI设备ID是2.

ubi2的volume0信息与ubinize.cfg 配置文件的内容一致。对于volume size，由于之前配置的是autoresize标志，这里自动拓展到了最大可用大小27.1 MiB。

$ ubinfo -a 
ubi2
Volumes count:                           1
Logical eraseblock size:                 253952 bytes, 248.0 KiB
Total amount of logical eraseblocks:     128 (32505856 bytes, 31.0 MiB)
......
Total amount of logical eraseblocks:     128 (32505856 bytes, 31.0 MiB)
......

Volume ID:   0 (on ubi2)
Type:        dynamic
Alignment:   1
Size:        112 LEBs (28442624 bytes, 27.1 MiB)
State:       OK
Name:        my_ubifs
Character device major/minor: 506:1

4.最后挂载ubifs

$ mount -t ubifs /dev/ubi2_0 /test

另外，我们也可以挂载一个空的ubifs(不需要ubi镜像)，操作步骤和上面差不多：

$ ubiformat /dev/mtd4

注意：如果/dev/mtd16为空(全0xFF)，不执行ubiformat也是可以的。但是如果/dev/mtd16为脏数据(非全FF),则必须进行ubiformat，否则ubiattach会报错。

$ ubiattach -p /dev/mtd4

# Create an UBI volume - the created volume will be empty

$ ubimkvol -N my_volume -s 10MiB /dev/ubi2
$ ubimkvol -N my_volume1 -m /dev/ubi2

卷1：my_volume 大小为10M
卷2：my_volume1 大小为ubi2剩余可用大小

$ ubinfo /dev/ubi2 -a
ubi2
Volumes count:                           2
Logical eraseblock size:                 253952 bytes, 248.0 KiB
Total amount of logical eraseblocks:     128 (32505856 bytes, 31.0 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  12
Current maximum erase counter value:     2
Minimum input/output unit size:          4096 bytes
Character device major/minor:            506:0
Present volumes:                         0, 1

Volume ID:   0 (on ubi2)
Type:        dynamic
Alignment:   1
Size:        42 LEBs (10665984 bytes, 10.1 MiB)
State:       OK
Name:        my_volume
Character device major/minor: 506:1
-----------------------------------
Volume ID:   1 (on ubi2)
Type:        dynamic
Alignment:   1
Size:        70 LEBs (17776640 bytes, 16.9 MiB)
State:       OK
Name:        my_volume1
Character device major/minor: 506:2

挂载/dev/ubi2_0和/dev/ubi2_1

# Mount UBIFS - it will automatically format the empty volume

$ mount -t ubifs /dev/ubi2_0 /test/
$ mount -t ubifs /dev/ubi2_1 /test1/
$ df -h
/dev/ubi2_0               5.9M     24.0K      5.5M   0% /test
/dev/ubi2_1              12.3M     28.0K     11.6M   0% /test1

清除UBI卷的方法如下：

$ ubiupdatevol /dev/ubi2_0 -t
$ ubiupdatevol /dev/ubi2_1 -t

参考

• Linux 内核驱动解析 - UBI坏块预留大小
• UBIFS - UBI File-System
• UBI File System