Ext4 fast commit 介绍

Ext4 Fast Commit 详解

📋 问题定位

• 所属子系统: Ext4 文件系统（fs/ext4/）
• 引入版本: Linux 5.10（2020年12月）
• 核心文件: fs/ext4/fast_commit.c，fs/ext4/ext4_jbd2.c
• 相关数据结构: struct ext4_fc_tl（tag-length 头部），struct ext4_fc_dentry_info（dentry变更记录），struct ext4_fc_inode（inode变更记录）

🎯 原理说明

背景问题

标准的 Ext4 使用 JBD2 (Journal Block Device 2) 作为日志系统。每次 fsync() / fdatasync() 调用时，JBD2 需要：

1. 将事务描述块、各元数据块依次写入 journal 缓冲区
2. 等待 journal I/O 完成
3. 更新 journal 的超级块（superblock）确认事务提交

这个过程虽然保证了崩溃一致性（crash consistency），但在高频元数据操作场景（如数据库事务日志、消息队列、容器元数据写入）中，每次 fsync 都要执行一次完整的事务提交，产生大量 journal 写入和磁盘 I/O，性能受限。

Fast Commit 设计思路

Fast commit 的核心思想是为频繁的 fsync 场景创建一条轻量级提交路径，将元数据变更记录为紧凑的 “fast commit block”，而不是完整的 journal 事务。

工作流示意：

普通 fsync 路径（JBD2 完整事务）：
   修改 inode → 启动 jbd2 事务 → 记录所有元数据块到 journal → 提交事务 → checkpoint
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   每次 fsync 都需要数百微秒到数毫秒

Fast commit 路径：
   修改 inode → 在内存中累积变更到 fast commit 域 → fsync 时：
                写入 fast commit block（紧凑格式）→ 更新 fc_replay_tid
   ^^^^^^^^^^^^^
   仅记录增量变更，延迟大幅降低

关键机制：

1. 增量记录机制：Fast commit 不复制完整的元数据块，而是仅记录自上次完整 checkpoint 以来发生了变更的 inode 和 dentry 信息。每条记录采用 TLV（type-length-value）格式，头部由 struct ext4_fc_tl 描述（4字节 tag + 4字节长度）。

2. 存储布局：Fast commit block 存储在 journal 区域的尾部，与普通 jbd2 事务共享同一磁盘区域。每个 fast commit 块包含一个 recovery TID（transaction ID），用于在恢复时确定最新的一致状态。

3. 崩溃恢复路径：
   • 系统启动时，Ext4 首先通过 jbd2 日志进行常规恢复
   • 然后扫描 fast commit 区域，从 fc_replay_tid 开始回放未完成提交的变更
   • 如果 fast commit 块校验和不匹配，跳过整个块，回退到上一个完整 checkpoint
4. 与 JBD2 的协作关系：
   • Fast commit 不是替代 jbd2 日志，而是其补充
   • 每隔一定次数（或显式调用 sync()）仍会执行完整 jbd2 事务提交，将累积变更通过传统路径 checkpoint 到磁盘
   • 每次 jbd2 checkpoint 后，fast commit 区域重置，开始新一轮累积

核心数据结构简化：

// fast commit 块头部（磁盘格式）
struct ext4_fc_head {
    __le32 fc_tid;          // 关联的 jbd2 事务 ID
    __le32 fc_features;     // 特性标志
};

// TLV 记录头部
struct ext4_fc_tl {
    __le32 fc_tag;          // 数据标签（EXT4_FC_TAG_INODE, TAG_DENTRY, 等）
    __le16 fc_len;          // 数据长度（不含此头部）
    __le16 fc_padding;      // 填充
};

💡 适用场景

💡 收益效果

根据 Ext4 维护者 Harshad Shirwadkar 在 2024-2025 年快照合入的优化补丁集数据：

💡 应用前景

1. 生产环境成熟度：Fast commit 自 Linux 5.10 合入主线后，经过 4 年多的迭代（包括 2025 年发布的新一轮性能优化补丁集），已具备较高稳定性。主流 Linux 发行版的 LTS 内核（5.10、5.15、6.1、6.6）均支持。

2. 配置方式：Ext4 fast commit 默认在格式化为 mkfs.ext4 启用 fast_commit 特性后自动开启。可通过：

   # mkfs.ext4 -O fast_commit /dev/sdX
   # mount -t ext4 /dev/sdX /mnt
   

3. 限制与注意事项：
   • Fast commit 对写频繁且 fsync 密集的负载收益最显著；对于大文件顺序写入且极少 fsync 的负载，收益有限
   • 需要 journal 设备有足够空间容纳 fast commit 区域
   • 在发生崩溃后恢复时，fast commit 回放会增加少量恢复时间
4. 发展趋势：Ext4 社区持续优化 fast commit 的内存开销和路径延迟，将其作为降低事务性 workload 写延迟的核心手段。随着 NVMe 等低延迟存储设备普及，fast commit 减少软件栈开销的价值会进一步凸显。

   参考来源

• 来源: http://172.17.0.1:9002/filesystems/dax.html