UTFS：一种面向嵌入式系统的“类 TAR”文件系统深度解读

背景

在嵌入式系统开发中，数据持久化是一个基础且普遍的需求。几乎所有嵌入式设备都需要将关键数据（如序列号、配置参数、功能设置等）存储到非易失性存储器（如 Flash 或 EEPROM）中。

传统的解决方案通常采用“固定数据结构”模式：在系统启动时读取数据，在参数变更时写入数据。虽然这种方法简单直接，但它存在严重的局限性，这些局限性会深刻影响固件的结构设计和可维护性。

以常见的 C 语言实现为例，开发者通常定义一个全局结构体 data_t，并在头文件 datastore.h 中声明 extern 变量。各个子系统（如 subsystem1.c、subsystem2.c）直接包含该头文件并访问全局变量。这种紧密耦合的方式带来了以下核心痛点：

1. 代码与数据结构的强耦合：数据存储结构的定义位于 datastore.c，并通过头文件全局暴露。任何对数据结构的修改都会导致所有包含该头文件的源文件重新编译，且可能引发子系统行为的不可预知变化。
2. 缓冲区溢出风险：由于数据在内存中连续排列，一个子系统的缓冲区溢出可能会破坏相邻子系统的数据。例如，若序列号字段 myserial 定义为 8 字节，但写入 12 字节的数据，溢出的部分将覆盖后续的 subsystem1_settings 等字段，导致难以追踪的 Bug。
3. 结构僵化：当业务需求变更（如序列号长度从 8 字符变为 16 字符）时，开发者往往需要在结构体中预留大量 unused 空间或重新排列字段，导致存储效率低下且维护困难。
4. 命名刚性：全局变量或成员变量的重命名需要修改固件中所有引用该变量的代码，违背了模块化设计原则。

为了解决这些问题，CLI Systems 开发了 UTFS (Micro TAR File System)，旨在将数据存储细节与应用层数据结构分离，实现子系统的隔离与独立更新。

核心内容

UTFS 是一种专为嵌入式系统设计的小型文件系统结构。它利用具有扁平地址空间的存储介质，通过基于字符串的文件名来组织数据，支持数据大小和位置的变化而不丢失数据。UTFS 主要面向读、更新、写操作，对流式或追加操作的支持有限。

设计灵感：从磁带驱动器到嵌入式存储

UTFS 的设计灵感来源于 20 世纪 70 年代的磁带驱动器。磁带驱动器是一种具有扁平内存地址空间的存储介质，不支持随机写入。为了解决这一问题，TAR 文件格式应运而生。TAR 格式通过在每个文件前添加一个 512 字节的头部（Header）来存储文件信息，随后以 512 字节为块写入数据。后续文件则通过追加头部和数据依次存储。

UTFS 结合了 TAR 归档的基本概念与内存块指针，允许在不依赖源代码实现的情况下，独立地存储和检索任意数据。

UTFS 的独特特性

1. 摒弃传统的“打开/关闭”范式

现代文件系统通常遵循“打开-读/写-关闭”的范式，这主要适用于流式或追加数据。然而，嵌入式系统更常采用“加载-修改-保存”（Load-Modify-Save）的工作流。因此，UTFS 没有 open 和 close 函数。所有数据在操作前加载到 RAM，或在保存时从 RAM 写入存储介质。

2. 极简的头部设计

标准的 TAR 头部为 512 字节，对于资源受限的微控制器（MCU）RAM 或 EEPROM 来说占比过大。UTFS 将头部精简至 24 字节，以保持八字节对齐。其中：

• 12 字节用于文件名（最大 11 个字符加上 C 字符串的 NULL 终止符 \0）。
• 16 位签名变量：由应用程序设置，用于版本管理。该签名随数据自动加载和保存，无需在文件内部的数据结构中额外添加信息。

接口与使用示例

UTFS 的接口基于指向 RAM 数据块的指针。当调用 utfs_load() 时，文件系统会从存储介质加载数据到 RAM 结构体中。应用程序可以修改 RAM 中的数据，随后调用 utfs_save() 将所有数据写回存储介质。

以下展示了三个子系统如何独立注册和管理数据，互不干扰：

subsystem1.c

#include "utfs.h"
typedef struct{
    int settings;
}s1data_t;

s1data_t s1data;
utfs_file_t s1file;

// 将 s1data 绑定到文件名 "file1"
utfs_set(&s1file, "file1", &s1data, sizeof(s1data));
// 注册文件
utfs_register(&s1file, UTFS_NOFLAGS, UTFS_NOOPT);

subsystem2.c

#include "utfs.h"
typedef struct{
    int data;
    int data2;
}s2data_t;

s2data_t s2data;
utfs_file_t s2file;

utfs_set(&s2file, "file2", &s2data, sizeof(s2data));
utfs_register(&s2file, UTFS_NOFLAGS, UTFS_NOOPT);

subsystem3.c

#include "utfs.h"
typedef struct{
    int myval;
}s3data_t;

s3data_t s3data;
utfs_file_t s3file;

utfs_set(&s3file, "file3", &s3data, sizeof(s3data));
utfs_register(&s3file, UTFS_NOFLAGS, UTFS_NOOPT);

utfs.h 核心接口

// 初始化文件系统
utfs_result_e utfs_init(bool verbose);

// 注册文件，将 RAM 数据块与文件名关联
utfs_result_e utfs_register(utfs_file_t * f, utfs_flags_e flags, utfs_options_e options);

// 设置文件属性：文件名、数据指针、数据大小
utfs_result_e utfs_set(utfs_file_t * fp, char * name, void * data, uint32_t size);

// 从存储介质加载所有数据到 RAM
utfs_result_e utfs_load();

// 将 RAM 中所有数据保存回存储介质
utfs_result_e utfs_save();

处理数据大小变化

在实际开发中，数据结构会随业务需求频繁变更。UTFS 允许数据在 RAM 中的大小与存储介质上的文件大小不一致。当 RAM 中的数据结构小于存储介质上的文件数据时，UTFS 能够处理这种差异，确保数据的完整性和兼容性（注：原文在此处截断，但根据上下文逻辑，其核心优势在于通过文件名标识数据块，而非依赖固定的内存偏移量，从而避免了因结构体大小变化导致的内存布局崩溃）。

关键要点

• 解耦设计：UTFS 通过将数据存储与应用程序逻辑分离，消除了子系统之间的强耦合。修改一个子系统的数据结构不会影响其他子系统，也无需重新编译整个固件。
• 内存安全：通过基于文件名的数据块隔离，UTFS 从根本上减少了缓冲区溢出导致相邻内存区域被破坏的风险，提升了嵌入式系统的稳定性。
• 极简资源占用：相比标准 TAR 格式的 512 字节头部，UTFS 将头部压缩至 24 字节，极大降低了 MCU 和 EEPROM 的资源开销。
• 版本管理支持：头部包含的 16 位签名变量允许应用程序进行版本控制，确保不同版本固件之间的数据兼容性。
• 加载-修改-保存模式：摒弃了传统的文件打开/关闭机制，采用更适合嵌入式场景的批量加载和保存策略，简化了 API 使用。
• 灵活性：支持数据大小和位置的变化，无需像传统结构体那样预留大量未用空间或重新排列字段。

意义与影响

UTFS 的出现为嵌入式系统的数据持久化提供了一种现代化的解决方案，