3.6 元数据的困境——管理数据的数据最难管
你有一座图书馆，但馆藏总目录在火里
想象一个场景：你是一个图书管理员。你在旷野上建了一座图书馆。书架一架一架立上去，目录一张一张编上去。图书馆很大、管理很完备——阅览区对着南边的山，借阅台朝着东边的路。里面有上百个藏书区，每一个都有索引。
三年后，你退休了。你的继任者接管了这座图书馆。他手里只有一个信封。信封里有三样东西：
- 馆藏总目录（Superblock）：这座图书馆的总信息——它在哪里、多大、用的是哪种书架体系、建在哪一年。
- 借阅登记卡（File Table）：谁借了哪本书——《红楼梦》在东区第三排、《三体》在西区第一排。
- 空闲架位图（Free Bitmap）：哪些书架区是空的，可以放新书。
现在想象：有人放了一把火。不是烧图书馆——是烧信封。馆藏总目录、借阅登记卡、架位图全都烧成了灰。你的继任者站在完好无损的图书馆面前，他什么也做不了。
他不知道这座图书馆归谁管。他不知道《红楼梦》在哪排书架。他不知道哪排书架是空的。
馆藏总目录丢了，图书馆就成了无主之地。借阅登记卡丢了，里面的书就找不到了。
这就是元数据的困境。
数据是藏书，元数据是馆藏目录
在文件系统的世界里，数据和元数据是两种完全不同的动物。
数据 vs 元数据
=======================
数据（Data）:
- 是用户关心的内容：文本、图片、标定参数、日志
- 体积大（KB~MB）
- 丢了一块：文件里有几个字节不对，通常可以忍受
或者文件只读一次就扔了
元数据（Metadata）:
- 是文件系统用来管理数据的数据
- 体积小（B~KB）
- 丢了一条：可能整个文件都找不到了
或者文件系统根本mount不起来
这种不对称性，是文件系统设计中最核心的矛盾。
让我们具体看看KnotFS里的元数据都由哪些东西组成：
KnotFS 元数据全景
=======================
1. Superblock (SB0/SB1, 块0/块1)
┌──────────────────────────────┐
│ magic: 0x4B4E4653 │ ← "KNFS" 识别这是一个KnotFS卷
│ version: 1 │ ← 文件系统版本
│ block_size: 4096 │ ← 块大小
│ block_count: 16 │ ← 总块数（教学版）
│ free_map: 0x0007 │ ← 空闲位图（32位，覆盖16个块）
│ log_offset/log_count: ... │ ← SB Log的读写指针
│ sequence: 0x0042 │ ← 单调递增的序列号
│ nodes[8]: {文件表嵌入在此} │ ← 最多8个文件条目
│ wear[16]: ... │ ← 每个块的擦除次数
│ crc32: 0x9A3B... │ ← 完整性校验
└──────────────────────────────┘
注意：文件表（nodes[8]）直接嵌入在SB Header中，不是独立块。
这意味着文件条的持久化依赖Compact操作——重写整个SB到备用槽位。
2. SB Log（嵌入在SB块内部，SB Header之后）
┌──────────────────────────────┐
│ [tag:USED│blk:4│val:1│crc] │ ← "块4被占用了"
│ [tag:USED│blk:5│val:1│crc] │ ← "块5被占用了"
│ [tag:FREE│blk:3│val:0│crc] │ ← "块3被释放了"
│ ... │
│ 每条约 8 字节 │
│ ~400条后触发compact │
└──────────────────────────────┘
3. File Table（嵌入在SB Header中的 nodes[8]）
┌──────────────────────────────┐
│ entry[0]: "config.txt" │ ← 文件名 (32字节)
│ size: 1024 │ ← 文件大小
│ blocks[0..7]: [4,0,0...] │ ← 直接块号数组
│ block_count: 1 │ ← 占用块数
│ │
│ entry[1]: "firmware.bin" │
│ size: 24576 │
│ blocks[0..7]: [5,6,7...] │
│ block_count: 6 │
│ ... │
│ (共8个entry，size=0表示空闲) │
└──────────────────────────────┘
文件表修改不走日志——累积在内存中，Compact时整体写入新SB。
4. Free Bitmap（嵌入在SB Header中的 free_map）
┌──────────────────────────────┐
│ bit[0] = 1 (SB0占用) │
│ bit[1] = 1 (SB1占用) │
│ bit[2] = 0 (空闲!) │
│ bit[3] = 0 (空闲!) │
│ bit[4] = 1 (被文件占用) │
│ bit[5] = 1 (被文件占用) │
│ ... 16个bit = 4字节（教学版） │
└──────────────────────────────┘
5. Wear Count Array（16 × uint32 = 64字节，教学版）
┌──────────────────────────────┐
│ block[0].wear = 35 │
│ block[1].wear = 42 │
│ block[2].wear = 28 │
│ ... │
│ 磨损计数，持久化到Flash │
└──────────────────────────────┘
这五类元数据加起来，总共约 700 字节（SB Header）。但它们的每一次错误——有一个bit错了——都可能导致灾难。
元数据的三大战略
在Flash文件系统中，保护元数据的可靠性和持久性有三个经典策略。KnotFS一个都没少。
策略一：双副本（Dual-Copy）——总不能两个都坏吧
双副本策略
=======================
SB0 (块0): [version=5, data...] ← 有效
SB1 (块1): [version=4, data...] ← 旧版本
选择规则：
if (SB0.sequence_number ≥ SB1.sequence_number)
使用 SB0
else
使用 SB1
写入规则：
总是写入"当前不是有效的那个副本"
写入完成后，新副本的sequence_number > 旧副本
原子地"切换"有效副本
问题：
如果写入过程中掉电 → 正在被写入的那个副本可能损坏
但旧副本仍然完整！
恢复时选择sequence_number大的（但必须是完整的，通过CRC验证）
双副本的代价是一倍的存储空间。对于KnotFS教学版，整个SB Header（~700字节，包含文件表 + free_map + wear[]）+ Log空间只需要2个块（SB0和SB1各4KB = 8KB），在64KB总空间里占12.5%。虽然比例不低，但对于教学级文件系统来说，可靠性优先于空间效率。
但双副本解决了最致命的问题：在写入元数据的过程中掉电，你总能回滚到上一个有效版本。
策略二：日志追加（Log Append）——只加一行，不重写整本书
日志追加策略
=======================
不做日志：
修改SB中的一个字段（4字节）
→ 擦除SB所在块（4KB, 200ms）
→ 重新编程整个SB块到Flash（4KB, ~58ms）
→ 写放大 = 4096 ÷ 4 = 1024倍
做日志：
修改SB中的一个字段
→ 在SB块末尾追加一条8字节的log记录
→ 编程8字节（~0.1ms, 直接追加, 不需要擦除）
→ SB块上有足够空间继续追加（直到50%满）
→ 写放大 ≈ 8 ÷ 4 = 2倍（因为实际的log记录可能比字段大一点）
SB 块内部布局:
┌─────────────────────────┐ ← 块起始
│ Superblock Header │ ← 512字节, 仅compact时重写
│ (不可变) │
├─────────────────────────┤
│ SB Log Record 1 │ ← 8字节, 追加写入
│ SB Log Record 2 │ ← 8字节
│ SB Log Record 3 │ ← 8字节
│ ... │
│ SB Log Record N │ ← 最新
├─────────────────────────┤
│ 空闲空间 (可追加) │
│ │
└─────────────────────────┘ ← 块结束
日志追加的精妙在于：它把“修改固定字段“变成了“在末尾追加一行记录“。 追加只需要把1变成0，不需要先擦除——因为追加的位置一定是干净的（之前没被写过）。这是对Flash单向编程特性的完美利用。
但日志会满。4KB的SB块，减去668字节的header（sizeof(knot_sb_t)），还剩3428字节。每条记录8字节，能装最多428条。当log记录数达到214条（50%）时，触发compact。
策略三：紧凑（Compact）——把日志浓缩成最新的那一版
Compact 流程
=======================
Compact前:
SB0 块内:
┌─────────────┐
│ Header v4 │
│ Log: seq=10 │ ← 旧mount记录
│ Log: seq=11 │ ← 旧write记录
│ Log: seq=12 │ ← 旧write记录
│ Log: seq=13 │ ← 最新：包含了所有累计的变更
│ [空白] │
└─────────────┘
Compact 过程:
1. 分配一个新的SB块 (比如块0→块1，或块1→块0)
2. 重放log：从第一条有效log到最新一条
累积所有变更 → 得到最新的完整superblock状态
3. 将最新的superblock header写入新块的头部
4. 新块的log区为空
5. 擦除旧块
Compact后:
新SB1 块内:
┌─────────────┐
│ Header v13 │ ← 包含了所有累计变更
│ [空白 log] │ ← 可以继续追加 ~448条新记录
│ │
│ │
└─────────────┘
这三种策略是三者都用，不是三选一。
- 双副本提供了写入过程中的掉电保护（总有一个有效副本）
- 日志追加提供了高效的元数据更新（不需要每次擦除整个块）
- 紧凑提供了日志空间的回收（防止log溢出）
三者形成了一个闭环：
元数据保护的闭环
=======================
修改元数据
↓
┌─ 追加一条log记录 ─→ log空间够吗？
│ │
│ 够 │ 不够
│ │
│ ✓ 完成 │
│ ↓
│ 触发 Compact
│ │
│ ↓
│ 双副本切换（写到另一个副本）
│ │
│ ↓
│ log区清空，循环继续
│ │
└────────────────────────┘
“图书馆“隐喻：馆藏总目录、借阅登记卡与架位图
让我们回到那个图书管理员的隐喻。在KnotFS管理的“图书馆“（Flash）里：
藏书区隐喻 → KnotFS 数据结构
=======================
馆藏总目录 = Superblock
内容：这座图书馆总共有多少个藏书区、结构版本是什么
丢了：你不知道这座图书馆归谁管
借阅登记卡 = File Table（嵌入在Superblock中）
内容：《红楼梦》在3号藏书区，《三体》在5号藏书区，《资治通鉴》在8号藏书区
丢了：你知道有《红楼梦》，但不知道它放在哪个藏书区
架位图 = Free Bitmap
内容：哪些藏书区空着、哪些被占了
丢了：你不知道新到的书该往哪个藏书区摆
书架的保养记录 = Wear Count
记录：3号藏书区的书架被整理了35次了
丢了：你不知道哪面书架最脆弱（磨损最多）
索书号校验 = CRC校验
每一张索书卡都验证：拿到的索书号对不对
不对：说明书被换过（数据损坏了）
管理图书馆的隐喻之所以强大，是因为它把“抽象的数据结构管理“变成了“具体的物理空间管理“——而后者是人脑最擅长的事情之一。
在这个隐喻里，元数据保护的三个策略变成了：
- 双副本 = 馆藏总目录一式两份，分别放在两个不同的保险柜里。烧了一个，还有一个。
- 日志追加 = 不是直接在总目录上涂改（涂改会让纸张损坏），而是在总目录后面贴一张便签条：“第3条修正：《红楼梦》移到12号藏书区了。日期×。签字×。“便签条越贴越多，但总目录本身没有被撕烂。
- 紧凑 = 把攒了几百张便签条的馆藏总目录拿出来，重新誊写一份干净的——所有的便签条信息都整合进了正文，便签条可以扔掉了。
元数据的工程哲学：冗余是唯一的道路
回到那个核心问题：为什么元数据最难管？
因为元数据的价值密度极高。
1KB的用户数据丢了，用户说：“哦，少了一行日志。” 1KB的超级块丢了，文件系统说：“我不知道我是谁了。mount失败。”
元数据的每一个bit，都“管理“着几百、几千倍于自身大小的数据。这个不对称意味着：元数据需要的可靠性水平是数据的一千倍以上。
在工程上，提高可靠性的唯一道路是冗余。双副本是空间冗余（两份拷贝）。日志追加是时间冗余（保留了修改历史）。CRC校验是校验冗余（信息论层面的冗余）。
KnotFS在~700字节的元数据（SB Header + 文件表）上投入了8KB的物理存储空间（SB0、SB1各占1个4KB块 = 8KB），以及数个数组的跟踪数据结构（wear[]、free_map）。
冗余率 = 8KB ÷ ~700B ≈ 12倍。
这不是浪费。这是对“元数据的价值密度是数据的一千倍“这一工程事实的理性回应。
下集预告
元数据的三个保护策略确保了你不会丢掉“馆藏总目录“和“借阅登记卡“。但图书馆本身——128个藏书区的书架——怎么管理？不是所有藏书区都会被同样程度地使用。如果3号藏书区被整理了十万次而99号藏书区几乎从没被用过，128号藏书区的整体寿命就被3号藏书区的天花板限制住了。
下一节，我们给每一面书架编号，跟踪它们的整理次数，确保每一面书架都均匀地老去——这就是磨损均衡的艺术。
悬念留给：动态磨损均衡只保证“新分配的块选最年轻的“。但如果有一块数据从写入后就再也没有被修改过——它占着那个块，块的磨损次数永远停在 3 次，而隔壁的热数据块已经被擦写了 8 万次。静态磨损均衡怎么解决这个问题？