ESC
输入关键词搜索文章标题和内容

从 MCU 到 Linux:机器人嵌入式文件系统选型指南

本文由 linuxROS 整理发布,首发于 linuxros.cn,转载请注明出处。

从 MCU 到 Linux:机器人嵌入式文件系统选型指南

导读:STM32 裸机和 Linux 系统,"存文件"完全是两套世界。MCU 选 LittleFS 还是 FatFS?NOR Flash 用 SquashFS 还是 UBIFS?本文从裸机→RTOS→Linux 全栈覆盖,附制作命令和决策流程,给你一点点参考。


一、存储介质与层级关系

选文件系统之前,必须先搞清楚四层关系:

┌─────────────────────────────────────────────────────────────┐
│  第一层:应用进程                                            │
│  读写文件:open("/data/config.txt")                        │
├─────────────────────────────────────────────────────────────┤
│  第二层:文件系统(ext4 / UBIFS / FAT32 / LittleFS)        │
│  负责:目录结构、权限管理、断电安全                          │
├─────────────────────────────────────────────────────────────┤
│  第三层:存储管理层(UBI / FTL)                            │
│  UBI:NAND 专用,统一处理坏块+磨损均衡                       │
│  FTL:eMMC/SD 卡内置,屏蔽坏块(对 Linux 透明)            │
├─────────────────────────────────────────────────────────────┤
│  第四层:物理介质                                          │
│  NOR Flash / NAND Flash / eMMC / SD / RAM                 │
└─────────────────────────────────────────────────────────────┘

关键澄清:

  • UBI ≠ 文件系统:UBI 是 NAND Flash 的管理层(第三层),UBIFS 是跑在 UBI 之上的文件系统(第二层)。说"SquashFS 是只读文件系统"是对的,但说"SquashFS 可以直接跑在 NAND 上"是错的——必须先有 UBI 层。
  • overlay ≠ 文件系统:overlay 是联合挂载技术,不是文件系统。它的下层(lower)通常是 SquashFS(只读),上层(upper)是 tmpfs 或 ext4(可写)。系统启动后实际看到的是一个"合成的可写系统",但底层 SquashFS 从未被修改。

1.1 存储介质对比

介质 硬件缺陷 第三层选择 第二层选择 推荐方案
NOR Flash 擦除慢、寿命有限(\~10万次) 无需(直接裸用) SquashFS(只读)、JFFS2(可写) SquashFS + overlay
NAND Flash 出厂坏块、写前必擦、寿命有限 UBI(统一管理坏块+磨损均衡) UBIFS(可写) UBI + UBIFS
eMMC 内置 FTL 屏蔽坏块(对 Linux 透明) 无需(FTL 内置) ext4 ext4
SD/MMC 质量参差、无磨损保护 无需 FAT32(boot)、ext4(数据) FAT32(boot) + ext4(rootfs)
RAM 掉电全丢、无容量上限危险 无需 tmpfs(设 size 上限) tmpfs

⚠️ JFFS2/YAFFS2 已淘汰:JFFS2 仍在内核但无活跃开发,YAFFS2 已移出主线内核。新项目统一用 SquashFS+overlay(NOR)和 UBI+UBIFS(NAND)。

1.2 存储介质与文件系统关系图

flowchart TB subgraph 物理层["第四层:物理介质"] NOR["NOR Flash"] NAND["NAND Flash"] EMMC["eMMC / SD"] RAM["RAM"] end subgraph 管理层["第三层:存储管理"] NONE1["(无需)"] UBI["UBI 层"] FTL["FTL(内置)"] NONE2["(无需)"] end subgraph 文件系统["第二层:文件系统"] SQ["SquashFS"] UB["UBIFS"] EX["ext4"] FA["FAT32"] TP["tmpfs"] end NOR --> NONE1 --> SQ NAND --> UBI --> UB EMMC --> FTL --> EX SD --> FTL --> FA RAM --> NONE2 --> TP style NOR fill:#E3F2FD,stroke:#1976D2 style NAND fill:#E3F2FD,stroke:#1976D2 style EMMC fill:#E3F2FD,stroke:#1976D2 style RAM fill:#E3F2FD,stroke:#1976D2 style NONE1 fill:#FFF8E1,stroke:#F57C00 style NONE2 fill:#FFF8E1,stroke:#F57C00 style UBI fill:#F3E5F5,stroke:#7B1FA2 style FTL fill:#FFF8E1,stroke:#F57C00 style SQ fill:#E8F5E9,stroke:#388E3C style UB fill:#E8F5E9,stroke:#388E3C style EX fill:#E8F5E9,stroke:#388E3C style FA fill:#E8F5E9,stroke:#388E3C style TP fill:#E8F5E9,stroke:#388E3C

一句话选型:NOR → SquashFS+overlay,NAND → UBI+UBIFS,eMMC → ext4,SD → FAT32(boot)+ext4,RAM → tmpfs。


二、MCU / RTOS 文件系统

MCU(STM32 / ESP32 / GD32 等)没有 Linux 内核,文件系统是纯软件库,直接操作 Flash 或 SD 卡。

2.1 LittleFS(MCU 首选)

定位:NOR Flash 专用,掉电安全 + 磨损均衡。GitHub 6.6k+ stars,ESP-IDF、Zephyr RTOS 均已官方集成。

为什么不是 FatFS:FatFS 断电可能导致文件损坏(无掉电保护、无磨损均衡)。LittleFS 靠 COW(Copy-on-Write)机制保证数据一致性。

# ===== 宿主机:制作镜像(可选,一般直接在 MCU 上格式化)=====
sudo apt install littlefs-fuse

# 调试时可用 FUSE 挂载查看镜像内容
lfs --block_size=4096 --read_size=16 --prog_size=16 littlefs_image.bin /mnt
// ===== 目标板:ESP-IDF 使用 LittleFS =====
// CMakeLists.txt
idf_component_register(SRCS "main.c" REQUIRES esp_littlefs)

// partitions.csv(定义存储分区)
# Name,   Type, SubType,  Offset,  Size
mydata,   data, spiffs,   0x210000, 0x100000

// main.c:挂载和读写
esp_vfs_littlefs_conf_t conf = {
    .base_path = "/littlefs",
    .partition_label = "mydata",
    .format_if_mount_failed = true
};
esp_vfs_littlefs_register(&conf);

// 正常读写文件(和标准 C 库完全一样)
FILE *f = fopen("/littlefs/config.txt", "w");
fprintf(f, "auto_start=1\n");
fclose(f);

2.2 FatFS(兼容王者)

定位:SD 卡 / MMC 专用,唯一优势是MCU 上写的文件 SD 卡拔下来插电脑就能读。

⚠️ 代价:没有掉电保护、没有磨损均衡。断电时如果正在写 FAT 表,整个文件系统可能损坏。频繁写入会加速 SD 卡物理损坏。

分支 Flash 占用 适用场景
FatFS(完整版) \~10KB ROM ESP32 / STM32F4 系列
Petit FatFS(精简版) \~2KB ROM 8/16 位 MCU,只有读功能
// ===== 目标板:STM32 HAL + FatFS =====
// CubeMX 勾选 FATFS → SD Card → 自动生成代码
FATFS fs;
f_mount(&fs, "", 1);
f_open(&file, "log.txt", FA_WRITE | FA_CREATE_ALWAYS);
f_printf(&file, "motor_speed=%d\n", 1500);
f_close(&file);

2.3 SPIFFS / NVS / FileX(补充方案)

方案 本质 适用场景
SPIFFS NOR Flash 可读写文件系统 ⚠️ ESP-IDF 官方标注"no ongoing development",仅 ESP8266 老项目维护,新项目换 LittleFS
NVS 键值存储(不是文件系统) ESP-IDF 配置存储,nvs_set_string("wifi", "ssid", "MyHome"),底层仍是操作 Flash
FileX + LevelX 带磨损均衡的 FatFS(ThreadX 生态) Azure RTOS / ThreadX 项目

2.4 MCU 选型速查

MCU 文件系统选型(裸机/RTOS):
════════════════════════════════════════════
NOR Flash(内置)     →  LittleFS(首选)
NOR Flash(ESP8266老)→  SPIFFS(仅维护)
SD Card               →  FatFS(兼容PC)
SD Card + 掉电要求    →  FileX + LevelX
纯配置键值             →  NVS(ESP32)
════════════════════════════════════════════

LittleFS 和 FatFS 不是互斥的——ESP32 项目通常是 LittleFS 存配置 + FatFS 管 SD 卡,各司其职。


三、Linux 文件系统拆解

3.1 SquashFS(只读镜像)

定位:固件系统分区专用。只读、压缩(LZ4/XZ/ZSTD)、挂载极快。

澄清:SquashFS 本身是只读文件系统(第二层),它必须跑在具体的物理介质或管理层之上:

  • NOR Flash:直接裸用 SquashFS
  • NAND Flash:必须先有 UBI 层
  • eMMC:直接裸用 SquashFS

OpenWrt 的 /rom 就是 SquashFS(原始镜像),/overlay 是可写层,两者叠加后呈现给用户的是一个"可写系统",但 /rom 本身从未被修改。

# ===== 宿主机:制作 SquashFS 镜像 =====
sudo apt install -y squashfs-tools

# 制作镜像
mksquashfs ./rootfs rootfs.squashfs -comp xz -b 256K

# 参数说明:
# -comp xz    : 压缩算法(xz 压缩率高,lz4 解压快)
# -b 256K     : 数据块大小
# -e "*.tmp"  : 排除指定文件

# 挂载验证(宿主机操作)
sudo mount -t squashfs -o loop rootfs.squashfs /mnt

正常输出示例:

Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on rootfs.squashfs, block size 262144.
Filesystem size 3847.23 Kbytes (3.76 Mbytes)
    50.23% of uncompressed filesystem size (7658.91 Kbytes)

3.2 JFFS2(NOR Flash 可写层)⚠️

定位:NOR Flash 可读写分区,存放持久化配置。⚠️ 已淘汰:仍在内核但无活跃开发,大容量 NOR(>32MB)挂载极慢。

来自 linuxros.cn · linuxROS
# ===== 宿主机:制作 JFFS2 镜像 =====
sudo apt install -y mtd-utils

# -s 页大小 -e 擦除块大小,必须与实际 Flash 芯片一致
mkfs.jffs2 -r ./config_dir -o config.jffs2 -s 256 -e 65536 --little-endian

参数获取方法:

```bash

===== 目标板:查看 MTD 参数(用于填充上方 mkfs.jffs2 参数)=====

cat /proc/mtd
mtdinfo /dev/mtd0
```

页大小和擦除块大小从芯片规格书或 mtdinfo 输出中获取。

3.3 YAFFS2(NAND Flash 可写层)⚠️

定位:NAND Flash 可读写文件系统。⚠️ 已淘汰:Linux 3.10 起移出主线内核,新项目用 UBI+UBIFS 替代。

# ===== 宿主机:编译 YAFFS2 工具(工具不在 Ubuntu 官方仓库)=====
git clone https://github.com/aleph1/yaffs2.git
cd yaffs2/utils && make

# 制作镜像(2048 = NAND 页大小,需匹配 Flash 芯片)
./mkyaffs2image ./rootfs rootfs.yaffs2 2048

3.4 UBI + UBIFS(NAND 全能方案)

定位:

  • UBI:NAND Flash 管理层(第三层),统一处理坏块+磨损均衡
  • UBIFS:跑在 UBI 之上的可读写文件系统(第二层)

当前嵌入式 NAND 方案的唯一主流选择。Buildroot、Yocto 默认推荐。

# ===== 宿主机:制作 UBIFS + UBI 镜像 =====
sudo apt install -y mtd-utils

# === 第一步:制作 UBIFS 镜像 ===
mkfs.ubifs -r ./rootfs -o rootfs.ubifs \
    -m 4096 -e 253952 -c 2000 \
    -x lzo -F

# 参数说明:
# -m 4096    : 最小 I/O 单元(从 mtdinfo "Minimum input/output unit size" 获取)
# -e 253952  : 逻辑擦除块大小 = 物理擦除块 - UBI 开销
# -c 2000     : 最大逻辑擦除块数(从 mtdinfo "Amount of eraseblocks" 获取)
# -x lzo     : 压缩算法(lzo 解压快,zlib 压缩率高)
# -F         : 第一次挂载时自动修复空闲空间

# === 第二步:打包为 UBI 镜像 ===
cat > ubinize.cfg << EOF
[ubifs]
mode=ubi
image=rootfs.ubifs
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
EOF

ubinize -o rootfs.ubi -m 4096 -p 256KiB ubinize.cfg

正常输出示例:

mkfs.ubifs: creating UBIFS image...
UBIFS filesystem: rootfs.ubifs, UBI device 0, volume 0
    min. I/O unit size: 4096 bytes
    logical eraseblock size: 253952 bytes
    file system size: 491101184 bytes (468.3 MiB)

3.5 FAT32(通用兼容格式)

定位:SD/MMC 卡通用格式,boot 分区首选。可读写、Windows/Linux/macOS 全通吃。

⚠️ 代价:无磨损均衡,频繁写入会加速 SD 卡损坏;单文件最大 4GB。

# ===== 宿主机:制作 FAT32 镜像 =====
sudo apt install -y dosfstools

# 方式1:直接格式化 SD 卡分区
sudo mkfs.vfat -F 32 -n BOOT /dev/sdc1

# 方式2:制作 FAT32 镜像文件
dd if=/dev/zero of=fat32.img bs=1M count=100
mkfs.vfat -F 32 fat32.img

# -F 32    : FAT 类型(12/16/32)
# -n BOOT  : 卷标名称

3.6 ext4(大容量全能方案)

定位:eMMC / SD 大容量首选,嵌入式 Linux 主力文件系统。可读写、日志保障断电安全、支持权限管理。

# ===== 宿主机:制作 ext4 镜像 =====
sudo apt install -y e2fsprogs

# 方式1:直接格式化分区
sudo mkfs.ext4 -L rootfs /dev/sdc2

# 方式2:制作 ext4 镜像文件(嵌入式常用)
dd if=/dev/zero of=rootfs.ext4 bs=1M count=512
mkfs.ext4 -L rootfs -d ./rootfs rootfs.ext4

# 参数说明:
# -L rootfs        : 卷标
# -d ./rootfs      : 预填充目录内容到镜像
# -T small         : 小文件系统优化(增加 inode 密度)
# -m 1             : 保留块比例(默认5%,嵌入式建议1%)

3.7 tmpfs(内存极速方案)

定位:纯内存运行,快启系统的运行时文件。读写极快、掉电即失、重启清空。

统一用 tmpfs(可设 size 上限防 OOM)。⚠️ ramfs 无限制、危险,直接忽略。

# ===== 目标板:挂载 tmpfs(设 size 上限,推荐)=====
sudo mount -t tmpfs tmpfs /mnt/tmpfs -o size=64M

# ===== 目标板:查看当前挂载的 tmpfs ======
mount | grep tmpfs
df -h | grep tmpfs

四、对比总表

文件系统 层级 存储介质 读写 压缩 磨损均衡 断电安全 新项目
SquashFS 文件系统 NOR/NAND/eMMC 只读 ✅ — ✅ ✅
UBIFS 文件系统 NAND 读写 ❌ ✅ ✅ ✅
ext4 文件系统 eMMC/SD 读写 ❌ ❌ ✅ ✅
FAT32 文件系统 SD/MMC 读写 ❌ ❌ ❌ ✅
tmpfs 文件系统 RAM 读写 ❌ — ❌ ✅
UBI 管理层 NAND — — ✅ — ✅
JFFS2 ⚠️ 文件系统 NOR Flash 读写 ❌ ✅ ✅ ❌
YAFFS2 ⚠️ 文件系统 NAND 读写 ❌ ✅ ✅ ❌
ramfs ⚠️ 文件系统 RAM 读写 ❌ — ❌ ❌

⚠️ 淘汰标记统一:JFFS2(维护停滞)、YAFFS2(移出主线内核)、ramfs(无限制危险)——新项目一律不碰。


五、决策流程图

flowchart TB A["选文件系统"] --> B{"存储介质?"} B -->|"NOR Flash"| C{"系统性质?"} C -->|"可更新配置"| D["overlay(tmpfs)"] C -->|"固化不动"| E["SquashFS 直接用"] C -.->|"⚠️ 老设备"| F["JFFS2"] B -->|"NAND Flash"| G["UBI + UBIFS"] B -->|"eMMC"| H["ext4"] B -->|"SD/MMC"| I{"用途?"} I -->|"Boot/跨平台"| J["FAT32"] I -->|"rootfs"| K["ext4"] B -->|"RAM"| L["tmpfs 设 size 上限"] style D fill:#E8F5E9,stroke:#388E3C style E fill:#E8F5E9,stroke:#388E3C style F fill:#FFEBEE,stroke:#D32F2F,stroke-dasharray:5 style G fill:#E8F5E9,stroke:#388E3C style H fill:#E8F5E9,stroke:#388E3C style J fill:#E8F5E9,stroke:#388E3C style K fill:#E8F5E9,stroke:#388E3C style L fill:#E8F5E9,stroke:#388E3C

六、常见选型踩坑

现象 根因 临时修复 量产规避
NOR Flash 写配置后不开机 JFFS2 无日志,开机全量扫描所有节点 减小 JFFS2 分区 新项目用 SquashFS+overlay
SD 卡频繁写入后损坏 FAT32 无磨损均衡 换 ext4,关闭 journal 选工业级 SD 卡,写操作转 tmpfs
NAND 运行一段时间后坏块增多 JFFS2 无坏块管理 迁移到 UBIFS NAND 必须上 UBI 层
tmpfs 存配置重启后丢失 tmpfs 纯内存,无持久化 配置改存 Flash 分区 启动脚本先 cp /flash/config /tmp
ext4 烧录后首次启动极慢 journal replay 需完整 fsck 用 -T small 减小分区 量产镜像用 mke2fs -E lazy_itable_init=0
mkfs.ubifs 报 Invalid argument UBI 参数与 Flash 物理特性不匹配 mtdinfo /dev/mtd0 重取参数 写入 Makefile 自动提取

调试命令:

# ===== 目标板:查看当前挂载的文件系统 =====
mount | grep -E "squashfs|ubifs|ext4|fat|tmpfs"

# ===== 目标板:查看 MTD 分区布局及物理参数(mkfs 参数来源)=====
cat /proc/mtd
mtdinfo /dev/mtd0

# ===== 宿主机:查看镜像文件信息 =====
unsquashfs -s rootfs.squashfs
dumpe2fs rootfs.ext4

七、总结

存储 推荐方案 说明
NOR Flash SquashFS + overlay(tmpfs) JFFS2 已淘汰
NAND Flash UBI + UBIFS YAFFS2 已淘汰
eMMC / SD ext4 + FAT32(boot) 大容量首选
RAM tmpfs(设 size 上限) 勿存持久数据

JFFS2 / YAFFS2 / ramfs —— 新项目一律不碰。


参考开源项目

项目 说明
littlefs-project/littlefs ARM 出品,MCU 专用文件系统,6.6k+ stars
FatFS MCU 领域 FAT 标准实现
ESP-IDF 乐鑫官方框架,内置 3 种文件系统(FatFS / SPIFFS / LittleFS)+ NVS 键值存储
Buildroot 嵌入式 Linux 构建系统,支持生成所有文件系统
OpenWrt squashfs + overlay 组合的典型范例
squashfs-tools SquashFS 官方工具集(2026-03 最新版)
mtd-utils MTD 工具集(2026-03 最新版 v2.3.1)

版权声明

作者linuxROS
协议本作品采用 CC BY-NC-SA 4.0 许可协议:署名-非商业性使用-相同方式共享
关注欢迎关注微信公众号 linuxROS,获取更多机器人 / 嵌入式 / Linux 干货
返回首页