Yaffs 根文件系统在嵌入式 Linux 中的构建与掉电可靠性实践

简介面向嵌入式系统开发者的技术参考文献围绕在NAND闪存设备上构建YAFFS根文件系统的实现过程展开适合从事系统移植、内核裁剪及存储管理的工程师和研究人员阅读。资源包内为1个PDF文档大小仅有151KB以期刊论文形式呈现篇幅紧凑、重点突出。内容从YAFFS针对NAND坏块与数据可靠性问题而专门设计的背景讲起说明了其日志机制、错误纠正技术以及可移植性优势随后完整梳理了在嵌入式Linux下实现该文件系统的步骤包括将YAFFS源码加入内核、修改配置菜单与编译规则、进行闪存分区、制作根文件系统镜像、烧录至目标设备并完成启动测试等。文中既有原理性分析也有可操作的命令行与文件修改示例对现场开发中的排错与调优很有帮助。目前已有133人学习依托专业期刊的权威性可作为嵌入式存储方案设计与问题排查时的常备参考资料。1. 嵌入式Linux 里的 Yaffs 根文件系统为什么到今天还在用提到嵌入式Linux根文件系统很多人第一反应是 ext4 或者 UBIFS。但在真实量产的工业主控、路由器、车载仪表里Yaffs 仍然大量存在尤其是 2KB 页 NAND、老内核、存储小于 128MB 的场景。原因很直接Yaffs 针对 NAND 的坏块、擦除和掉电问题设计挂载比 JFFS2 快适配比 UBIFS 简单几百 KB 的根文件系统也能稳定跑。这篇文章按嵌入式Linux项目里最常见的工程路径走一遍先讲 VFS 和 Flash 特性决定了什么再实际操作 BusyBox、镜像制作、内核参数最后用掉电测试验证可靠性。适合正在做嵌入式Linux驱动开发和系统裁剪优化的工程师也适合刚进入嵌入式Linux学习路线、想在真实板子上把根文件系统跑起来的开发。2. 从 VFS 到底层 NANDYaffs 的设计与选型逻辑2.1 NAND 的物理限制为什么 ext4 和 FAT 不适合直接上NAND Flash 和普通块设备有三个根本差异。第一写入前必须先擦除到 0xFF而擦除的最小单位是块block不是页page第二坏块出厂就有使用过程中还会继续增加文件系统必须能识别并跳过坏块第三每个页写入后要通过 OOBOut-of-Band区域存放 ECC 校验信息读回时如果发生 bit flip要靠这些校验位纠错。这几个特性放在一起等于直接否定了把 ext4、FAT 这类面向块设备的文件系统原样搬到 NAND 上的做法。就算用 mtdblock 把 NAND 模拟成块设备文件系统本身也不知道哪里是坏块更不知道擦除和写放大是什么概念。真正合适的是 Flash 专用文件系统它们把坏块管理、擦除块分配、磨损均衡、掉电恢复都放进文件系统自己的逻辑里。Yaffs 就是其中做得非常直接的一个。嵌入式Linux面试里经常问“为什么 Flash 文件系统和普通文件系统不一样”答案往往不在 VFS 层而在 MTD 层。MTD 把 NAND 抽象成字符设备 /dev/mtdN 和块设备 /dev/mtdblockNYaffs 直接操作 MTD 字符设备不经过通用块设备层的请求队列这是它后续所有行为的前提。2.2 VFS 挂载视角里的 Yaffs没有日志也算日志结构文件系统从 VFS 角度看Yaffs 和其他文件系统一样通过注册file_system_type结构体进入内核挂载时提供.mount回调读写时提供.read_iter、.write_iter等操作集。差别在于Yaffs 把文件切成固定大小的 chunk大页 NAND 通常一个 chunk 就是 2048 字节文件名、对象 ID、chunk ID、序列号、时间戳这些元数据放在 OOB 区域而不是单独占一个索引块。写入文件时Yaffs 不会覆盖旧数据而是找一个新的空闲 chunk 写入并给这个 chunk 分配更高的序列号。扫描 NAND 时如果发现同一个对象、同一个 chunk ID 存在两个版本只认序列号高的那一个旧 chunk 进入垃圾回收。这种设计让掉电变得没那么可怕就算新数据只写了一半旧数据仍然完整存在系统重启后自然丢弃不完整的部分。这也是 Yaffs 名字里 Yet Another Flash File System 的由来——它没有传统日志但本质上是一种日志结构文件系统。为了加速挂载Yaffs 会把扫描结果作为 checkpoint 写进 NAND。有 checkpoint 时挂载可以在几百毫秒内完成没有 checkpoint就要全盘扫描 OOB 重建目录树。工程上有个容易踩的坑如果掉电恰好发生在 checkpoint 更新的窗口里这个 checkpoint 可能损坏下次挂载会明显变慢甚至需要重新扫描。量产设备如果对启动时间敏感很多人会直接关掉 checkpoint用扫描时间换稳定性。2.3 Yaffs、JFFS2、UBIFS 怎么选三个维度做决定JFFS2、Yaffs2、UBIFS 是目前嵌入式Linux里最常见的三种 Flash 文件系统方案。选型可以从挂载速度、内存占用、OOB 依赖、恢复机制四个维度对比。对比维度JFFS2Yaffs2UBIFS挂载速度慢节点扫描多较快主要扫 OOB 标签快但依赖 UBI attach 过程内存占用随文件节点数线性增长相对可控UBI 后台活动占用略高对 OOB 的依赖不强强OOB 布局必须一致利用 OOB但管理在 UBI 层掉电恢复扫描日志节点序列号 checkpointLEB 管理 日志典型场景老内核、小分区小 NAND、老内核、要求快速挂载大容量、现代内核、复杂写入如果项目里的 NAND 只有 64MB页大小 2KB内核还是厂商提供的老 BSP直接选 Yaffs2 基本不会有争议。如果内核已经到 4.19 以上NAND 在 256MB 以上UBIFS 更合适因为 UBI 层在坏块管理和磨损均衡上做得更系统但它引入了一层逻辑擦除块重映射问题排查起来比 Yaffs 复杂。这里还要区分 YAFFS1 和 YAFFS2。早期小页 NAND 是 512 字节页 16 字节 OOB对应 YAFFS1现在量产 NAND 基本都是 2KB 页 64 字节 OOB对应 YAFFS2。所以标题里说 Yaffs 根文件系统实际操作时几乎都在用yaffs2这个文件系统类型而内核配置项却还叫CONFIG_YAFFS_FS这个命名错位容易让人困惑但不用管记住最终挂载类型写yaffs2就行。3. 用 BusyBox 和 mkyaffs2image 做出可启动的 Yaffs 根文件系统3.1 交叉编译 BusyBox 时配置CONFIG_STATICrootfs 会简单很多制作 Yaffs 根文件系统的第一步是先准备一个最小 rootfs 目录。常见做法是用交叉工具链加 BusyBox 手工搭建而不是一上来就套 buildroot。手工走一遍能看清楚每一个文件为什么存在后面做系统裁剪优化时才知道哪些可以动。交叉编译 BusyBox 的最小流程export ARCHarm export CROSS_COMPILEarm-linux-gnueabihf- make defconfig make menuconfig make -j$(nproc) make install CONFIG_PREFIX/home/user/rootfsmenuconfig 里最关键的选项是 BusyBox Settings → Build Options 下的CONFIG_STATICy这会让 BusyBox 静态链接 libcrootfs 里就不用带 libc.so 和 ld-linux.so。对于 64MB 的小 NAND 来说省掉一套 C 库能少几 MB 空间动态链接虽然镜像小但要额外拷贝库文件版本不匹配时排错很绕。make install CONFIG_PREFIX...会把编译好的 busybox 和符号链接安装到指定目录生成 bin、sbin、usr/bin 这些目录结构。有一点要注意如果后续用动态链接make install只会装 busybox 本体不会自动拷贝依赖库需要自己用arm-linux-gnueabihf-ldd busybox查看依赖并手动复制。3.2 手工搭 rootfs 目录和设备节点BusyBox 安装完之后需要补齐系统运行必须的目录和设备节点ROOTFS/home/user/rootfs mkdir -p $ROOTFS/{bin,sbin,etc/init.d,proc,sys,dev,tmp,usr/lib,lib} # busybox 是动态链接时才需要执行这一段 arm-linux-gnueabihf-ldd $ROOTFS/bin/busybox | awk {print $3} \ | xargs -I{} cp {} $ROOTFS/lib/ sudo mknod -m 600 $ROOTFS/dev/console c 5 1 sudo mknod -m 666 $ROOTFS/dev/null c 1 3 cat $ROOTFS/etc/init.d/rcS EOF #!/bin/sh mount -t proc none /proc mount -t sysfs none /sys mount -t tmpfs none /dev mdev -s EOF chmod x $ROOTFS/etc/init.d/rcSmknod那两行很重要。内核启动早期没有 udev、没有 devtmpfs如果 /dev/console 不存在内核就没办法把标准输入输出交给 init系统会直接起不来。主设备号 5 是字符设备 console主设备号 1 是 memory 设备null 的次设备号是 3。这个数字要和内核源码里的Documentation/admin-guide/devices.txt保持一致不能凭印象写。rcS 脚本里mount -t tmpfs none /dev配合mdev -s是嵌入式Linux里最常用的动态设备管理方案。mdev 是 BusyBox 自带的扫描 /sys 信息后在 /dev 下创建对应节点省去了为每个外设手工mknod的麻烦。如果是极小系统也可以不挂 tmpfs直接把所有设备节点静态做进镜像里但后续驱动一多就不好维护。3.3 生成完整 NAND 镜像mkyaffs2image 与烧写对齐rootfs 目录整理完成后需要用 mkyaffs2image 把它做成 Yaffs2 镜像。这个工具不是内核自带的常见做法是从开源社区维护的 yaffs2-utils 源码交叉编译出来。它和 tar、cpio 完全不同tar 打包的是字节流而 mkyaffs2image 会按 Yaffs2 的 chunk 布局、OOB 标签格式生成内容烧进 NAND 后挂载时才能直接从 OOB 读出对象 ID 和 chunk ID。生成镜像的命令很简单./mkyaffs2image rootfs rootfs.yaffs2 ls -lh rootfs.yaffs2部分版本的 mkyaffs2image 支持通过参数指定 OOB 大小例如 2KB 页 64 字节 OOB 的 NAND 要传对应值。这个参数必须和内核实际使用的 OOB 布局一致否则挂载时会出现大量 ECC 错误表现就是文件能列出但读出来全是乱码或者直接 I/O error。烧写时有一个比想象中更常见的坑。量产烧录时如果只把实际文件数据写进 NAND而分区尾部没有完全格式化旧数据残留的 Yaffs 标签会和新镜像交织在一起。Yaffs 扫描时看到同一个 chunk ID 存在两代数据会按序列号选择新的。看起来没问题但那些残留标签会占用有效空间也可能在后续 GC 中干扰坏块判断。稳妥的做法是先整分区擦除再写入完整镜像# U-Boot 环境 nand erase.part rootfs tftp 0x82000000 rootfs.yaffs2 nand write 0x82000000 rootfs ${filesize}3.4 内核侧配置YAFFS 选项与 MTD 分区文件系统做出来了内核这边也要把对应的配置打开。Yaffs 相关内核选项在不同版本里略有差异但下面这几个是通用的内核配置项作用CONFIG_YAFFS_FS启用 Yaffs 文件系统必选CONFIG_YAFFS_YAFFS2支持 YAFFS2 格式NAND 页大小 2KB 以上时必选CONFIG_YAFFS_AUTO_YAFFS2挂载时自动识别 yaffs1/yaffs2建议开启CONFIG_YAFFS_DISABLE_LAZY_LOAD关闭懒加载文件内容在挂载后立即可用CONFIG_MTD_NAND_XXX对应 NAND controller 驱动例如 MXC、OMAP、STM32 FMC如果 NAND controller 启用了硬件 ECCOOB 区域的前若干字节会被硬件占用Yaffs 的标签就必须按硬件规定的偏移存放。这个约束在 mkyaffs2image、烧写工具、内核驱动三者之间必须对齐。很多时候内核明明编了 Yaffs镜像也是 mkyaffs2image 生成的但挂载还是报 ECC 错误问题就出在这里。设备树里 NAND 节点的分区配置也要和 U-Boot 里mtdparts一致否则内核看到的 MTD 分区和实际 NAND 布局对不上就会出现“root 分区拧到 kernel 分区上”这种启动失败。4. 把 Yaffs 根文件系统挂到 NAND启动参数、挂载命令与四个常见错误4.1 mtdparts 分区规划与启动参数Yaffs 镜像做好后启动参数里必须同时明确根设备、文件系统类型、MTD 分区布局。一个典型的 U-Boot 环境变量如下setenv bootargs consolettyS0,115200 root/dev/mtdblock6 rootfstypeyaffs2 \ mtdpartsnand0:4m(boot),2m(kernel),64m(rootfs)mtdparts里定义了三段分区按顺序编号从 0 开始所以 4m boot 区是 mtd02m kernel 区是 mtd164m rootfs 区是 mtd2。如果分区表里还有其他内容root 对应的 mtdblock 编号要顺着往下数这里只是示例。root/dev/mtdblock6和rootfstypeyaffs2是另一处容易混淆的地方。Yaffs 在运行时挂载通常用字符设备 /dev/mtd/mtdN但内核根文件系统挂载阶段对root参数的解析普遍走块设备路径所以大量平台实际用的是mtdblockN。如果你的内核和 BSP 不接受这种组合更可靠的方案是先用 initramfs 把系统拉起来rootfs 运行时再执行mount -t yaffs2 /dev/mtd/mtd2 /mnt配合switch_root。两种做法工程上都存在第一种简单直接第二种更符合 Yaffs 的 MTD 字符设备特性。4.2 运行期挂载 Yaffs 分区的常用命令系统启动后如果需要把 Yaffs 分区挂到某个目录常见做法是mkdir -p /mnt/data mount -t yaffs2 /dev/mtd/mtd2 /mnt/data df -h /mnt/data这里用的设备名是/dev/mtd/mtd2不是/dev/mtdblock2。因为 Yaffs 直接基于 MTD 字符设备访问 NAND不走 mtdblock 的块设备模拟层。这样写放大更小也更符合 Yaffs 的设计意图。df -h /mnt/data可以确认挂载是否成功、分区剩余空间多少。挂载失败时的第一反应应该是看 dmesg而不是重新烧镜像。dmesg | grep -i yaffs能看到 Yaffs 打印的挂载过程信息包括扫描了多少 chunk、是否启用了 checkpoint、有没有 ECC 错误。这些信息比 mount 命令返回的错误码有价值得多。4.3 挂载失败排查顺序与常见错误对照把 Yaffs 根文件系统挂到 NAND 时最常碰到的几个问题可以先用下面的表对一下现象原因处理方向kernel panic: VFS: Unable to mount root fsrootfstype 没写或内核没编 Yaffs检查 CONFIG_YAFFS_FS显式加 rootfstypeyaffs2mount: No such device内核无 Yaffs或 MTD 分区没注册cat /proc/mtd 看分区是否存在mount: Invalid argumentOOB 布局不匹配或文件系统类型写错 yaffs/yaffs2确认镜像 OOB 大小、ECC 配置yaffs: dev is null 或 Magic not found烧写位置错、镜像空、分区没擦干净重新 erase.part 并写入完整镜像排查顺序很有讲究。先cat /proc/mtd确认内核看到的 MTD 分区和 U-Boot 里规划的一致再确认设备节点 /dev/mtd/mtd2 是否存在接着看 dmesg 里 Yaffs 有没有打印扫描信息。如果提示 Magic not found用nanddump -f /tmp/dump.bin /dev/mtd2读回前几页看看内容是全 0xFF 还是有 Yaffs 的标签结构。全 0xFF 说明分区擦过但没写进去或者烧写地址不对。还有一个很现实的问题Yaffs 没有像 e2fsck 那样的专用修复工具。文件系统损坏后常见做法是擦掉分区重新烧写最多对可写区域做格式化处理。所以量产系统里通常把 rootfs 做成只读或半只读真正频繁写入的数据单独放一个分区这样即使一个分区坏了系统还能启动这就是系统裁剪优化里“分离只读区与数据区”的典型理由。4.4 影响掉电与扫描速度的挂载选项说明Yaffs 挂载时还有一些选项会影响行为和性能mount -t yaffs2 -o no_checkpoint /dev/mtd/mtd2 /mnt/data mount -t yaffs2 -o inband_tags /dev/mtd/mtd2 /mnt/datano_checkpoint关闭 checkpoint 写入每次挂载都全盘扫描。优点是不会出现 checkpoint 损坏导致的恢复异常缺点是挂载时间变长。对于 64MB 分区全盘扫描通常也就一两秒但对启动时间要求苛刻的产品来说这个差距要实际测。inband_tags则把 Yaffs 标签从 OOB 挪到数据区尾部适合硬件 ECC 占满 OOB 的场景代价是有效存储容量下降。这两个选项的具体名称在不同内核补丁版本里可能有差异最稳的确认方式是看源码里解析 options 的那段代码或者在挂载失败时看内核打印的可用选项。性能调优时要注意sync不是 Yaffs 的挂载选项不要指望给 mount 加个 sync 就能解决掉电问题。Yaffs 有自己的后台线程负责回写和垃圾回收简单粗暴地大量调用 fsync 反而会把脏页集中刷入加剧写放大。5. 用一组掉电脚本验证 Yaffs 的可靠性顺便做性能调优根文件系统能启动只是第一步真正可怕的是掉电几次之后再开机目录结构已经损坏。Yaffs 的可靠性验证不能靠手摸要用脚本反复写、随机断电、重启校验。下面这个脚本可以在目标板上直接跑#!/bin/sh P/mnt/nand i0 while [ $i -lt 100 ]; do dd if/dev/urandom of$P/blob.bin bs64K count16 2/dev/null sync md5sum $P/blob.bin $P/SUM sync i$((i1)) sleep 0.2 done echo done, now kill power脚本里的两次 sync 不是多余的。第一次 sync 把 blob.bin 数据真正写到 NAND第二次把校验文件 SUM 也落盘。掉电后重启执行md5sum -c $P/SUM。如果校验失败但文件还在说明 Yaffs 恢复了旧版本数据这类情况要看是不是 ECC 纠错限制导致的问题如果文件缺失或 SUM 本身丢失说明元数据写入和文件内容写入在掉电瞬间没有保持一致性需要在应用层按业务需要做折中。比单一大文件更贴近真实的是多文件、多层目录的验证。Yaffs 的目录项也存放在 chunk 里目录层级越深、文件越碎越容易暴露出扫描和 GC 的问题D/mnt/nand/d$(date %s) mkdir -p $D/sub for s in 1k 8k 64k 512k; do dd if/dev/urandom of$D/sub/f_$s bs$s count1 2/dev/null done find $D -type f -exec md5sum {} \; | tee /mnt/nand/dir.md5 sync磨损均衡的验证需要看块擦除次数。部分内核树的 Yaffs 驱动会通过 /proc/yaffs 暴露每个块的状态和擦除计数如果你的 BSP 没有可以用 mtd-debug 连续读写后观察坏块表变化。判断磨损均衡是否生效看的是最大擦除次数和最小擦除次数之间的差距差距超过一个数量级说明 GC 总是在搬运一小块区域均衡策略没有真正工作。最后一个具体技巧如果产品频繁掉电且不能接受每次都做全盘 sync把日志类小文件从 Yaffs 分区挪出去日志先写 tmpfs再按固定周期搬运到 Yaffs。这样不仅避免小碎块碎片化也减少后台 GC 的写放大。Yaffs 更适合放“低频、整块、可容忍旧版本恢复”的数据那些几十字节一次的高频日志是最容易让磨损均衡失效的模式。本文还有配套的精品资源点击获取