实战案例3：文件系统元数据结构设计

文件系统，说白了就是硬盘上的「档案管理员」。它得知道每个文件叫什么、有多大、存在哪。这些信息，就是元数据。今天咱们就用C语言的结构体、位域、内存对齐这些家伙，来设计一个精简的文件系统元数据结构。

我个人习惯，在设计这类底层结构时，先画一张图，把脑子里的想法理清楚。你看下面这张图，就是咱们要实现的元数据核心逻辑：

1. 需求分析：元数据里该放什么？

一个文件系统，至少得知道这些：

• 文件名：总不能叫「无名氏」吧。我一般用固定长度数组，比如32字节，省得搞动态内存分配，在嵌入式场景下容易出问题。
• 文件大小：用uint32_t，最大支持4GB文件，够用。
• 权限位：读、写、执行，分属主、组、其他人，一共9位。你想想看，用三个uint32_t是不是太浪费了？
• 时间戳：创建时间、修改时间，用uint32_t存Unix时间戳。
• 数据块指针：指向文件实际数据在磁盘上的位置。我习惯用12个直接指针，再加一级间接指针，这样小文件不用跳转。

2. 第一版：默认对齐，看看有多大

先写个最直接的版本，看看编译器会搞出什么名堂：

struct FileMeta {
    char     name[32];       // 32字节
    uint32_t size;           // 4字节
    uint32_t perm;           // 4字节 —— 其实只需要9位
    uint32_t create_time;    // 4字节
    uint32_t modify_time;    // 4字节
    uint32_t block_ptr[12];  // 48字节
    uint32_t indirect_ptr;   // 4字节
};

算一下：32+4+4+4+4+48+4 = 100字节。嗯，理论上100字节。但实际呢？

printf("sizeof(FileMeta) = %zu\n", sizeof(struct FileMeta));
// 在我的机器上输出：104

多了4个字节！为什么？因为uint32_t要求4字节对齐，name数组占了32字节，后面size的起始地址是32，能被4整除，没问题。但编译器可能在结构体末尾填充了4字节，让整个结构体大小是4的倍数。这就是对齐的「副作用」。

printf("offset of size: %zu\n", offsetof(struct FileMeta, size));
printf("offset of perm: %zu\n", offsetof(struct FileMeta, perm));

3. 第二版：位域压缩权限位

权限位明明只需要9位，用uint32_t太奢侈了。用位域来搞：

struct FileMeta {
    char     name[32];
    uint32_t size;
    // 权限位：9位就够了
    uint32_t owner_read  : 1;
    uint32_t owner_write : 1;
    uint32_t owner_exec  : 1;
    uint32_t group_read  : 1;
    uint32_t group_write : 1;
    uint32_t group_exec  : 1;
    uint32_t other_read  : 1;
    uint32_t other_write : 1;
    uint32_t other_exec  : 1;
    // 还剩23位没用，可以留给以后
    uint32_t reserved    : 23;
    uint32_t create_time;
    uint32_t modify_time;
    uint32_t block_ptr[12];
    uint32_t indirect_ptr;
};

你可能会想：「这下省了3个字节吧？」 嗯，没那么简单。位域成员仍然占用一个完整的uint32_t，只是在这个32位里重新分配了位。所以perm字段从4字节变成了还是4字节，但好处是——我们把9个权限位塞进了一个32位变量里，语义更清晰了。

4. 第三版：手动控制对齐，消除填充

为了可移植性和紧凑存储，我一般用两种方法：

方法A：使用#pragma pack

#pragma pack(push, 1)  // 1字节对齐，取消填充
struct FileMetaPacked {
    char     name[32];
    uint32_t size;
    uint32_t perm_bits : 9;
    uint32_t reserved  : 23;
    uint32_t create_time;
    uint32_t modify_time;
    uint32_t block_ptr[12];
    uint32_t indirect_ptr;
};
#pragma pack(pop)

printf("sizeof(FileMetaPacked) = %zu\n", sizeof(struct FileMetaPacked));
// 输出：100 —— 正好是成员大小之和

这下没有填充了，100字节，干干净净。但是——访问速度会变慢，因为CPU访问未对齐的数据需要额外操作。在嵌入式系统或者性能敏感的场景下，要权衡。

方法B：手动排序成员，减少填充

如果不喜欢#pragma pack，可以手动把成员按大小从大到小排列，让编译器自然对齐：

struct FileMetaAligned {
    uint32_t block_ptr[12];  // 48字节 —— 最大的放前面
    uint32_t size;           // 4字节
    uint32_t create_time;    // 4字节
    uint32_t modify_time;    // 4字节
    uint32_t indirect_ptr;   // 4字节
    uint32_t perm_bits;      // 4字节
    char     name[32];       // 32字节 —— 数组放最后
};

printf("sizeof(FileMetaAligned) = %zu\n", sizeof(struct FileMetaAligned));
// 输出：100 —— 也没有填充

你看，通过调整成员顺序，也能达到紧凑布局。我个人更推荐这种方法，因为它不依赖编译器扩展，可移植性更好。

5. 序列化与反序列化

结构体在内存里是一回事，写到磁盘上是另一回事。你不能直接fwrite整个结构体，因为：

• 不同机器的大小端不同
• 位域布局不同
• 填充字节不同

所以，我一般会写专门的序列化函数：

void file_meta_serialize(const struct FileMeta *meta, uint8_t *buf) {
    // 用固定顺序、固定大小写入缓冲区
    memcpy(buf, meta->name, 32);           buf += 32;
    *((uint32_t*)buf) = meta->size;        buf += 4;
    // 权限位打包成一个uint32_t
    uint32_t perm = 0;
    perm |= meta->owner_read  << 0;
    perm |= meta->owner_write << 1;
    // ... 其他位
    *((uint32_t*)buf) = perm;              buf += 4;
    *((uint32_t*)buf) = meta->create_time; buf += 4;
    *((uint32_t*)buf) = meta->modify_time; buf += 4;
    for (int i = 0; i < 12; i++) {
        *((uint32_t*)buf) = meta->block_ptr[i];
        buf += 4;
    }
    *((uint32_t*)buf) = meta->indirect_ptr;
}

// 反序列化同理，从buf中按顺序读取

这样做的好处是：不管你在什么平台、用什么编译器，写出来的二进制格式都是一样的。这就是「可移植性」的代价——多写几行代码。

6. 总结：设计元数据结构的几个原则

嗯，文件系统的元数据设计，说白了就是一场「空间 vs 时间 vs 可移植性」的博弈。没有银弹，只有根据场景做取舍。我当年第一次设计时，恨不得把所有字段都塞进一个结构体，结果跨平台时吃尽了苦头。后来学乖了——先想清楚数据要到哪里去，再决定结构体怎么摆。