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

LinuxROS · 2026-9-6 09:54:09

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 │

└─────────────────────────────────────────────────────────────┘

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 存储介质与文件系统关系图

选型：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）挂载极慢。

# ===== 宿主机：制作 JFFS2 镜像 =====

sudo apt install -y mtd-utils

# -s 页大小 -e 擦除块大小，必须与实际 Flash 芯片一致

mkfs.jffs2 -r ./config_dir -o config.jffs2 -s 256 -e 65536 --little-endian

参数获取方法：

# ===== 目标板：查看 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（无限制危险）——新项目一律不碰。

---

五、决策流程图

六、常见选型踩坑

现象	根因	临时修复	量产规避
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 自动提取

调试命令：

# ===== 目标板：查看当前挂载的文件系统 =====

# ===== 目标板：查看 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 上限）	勿存持久数据