3. XFS日志原理：日志记录类型、事务流程与检查点

XFS 作为高性能 64 位日志文件系统，其日志（Journal）机制是保证元数据一致性与快速恢复的核心。理解日志记录类型、事务工作流程以及检查点机制，是进行 XFS 性能调优的前提。本章将深入剖析这三个关键环节。

3.1 日志记录类型：元数据日志 vs 数据日志

XFS 默认仅记录元数据（Metadata）的变更，称为元数据日志（Metadata Journaling）。这意味着只有文件系统的结构信息（如 inode、目录项、空闲空间映射）被写入日志，而文件的实际数据内容则直接写入数据块。这种模式在保证文件系统一致性的同时，大幅减少了日志写入量，是 XFS 高性能的核心原因之一。

XFS 也支持数据日志（Data Journaling）模式，即同时将文件数据和元数据都写入日志。这提供了更强的数据安全保障（例如，系统崩溃后不会出现数据与元数据不一致导致的“脏数据”），但代价是日志写入量成倍增加，性能显著下降。XFS 的数据日志模式通常通过挂载选项 data=journal 启用，但在生产环境中较少使用。

3.2 日志事务（Transaction）的工作流程

XFS 将文件系统操作封装为事务（Transaction）。一个事务代表一组原子性的元数据更新操作。事务的工作流程遵循经典的“预写日志（Write-Ahead Logging）”原则，确保在系统崩溃时，要么事务完整提交，要么完全不生效。

下图展示了 XFS 日志事务从开始到提交的完整生命周期：

事务工作流程的详细步骤如下：

1. 事务开始（Transaction Start）： 调用 xfs_trans_alloc() 分配一个事务结构体，标记事务开始。
2. 锁定与预留（Lock & Reserve）： 调用 xfs_trans_reserve() 锁定相关资源（如 inode、buffer），并在日志中预留足够的空间，确保事务能够原子完成。
3. 修改操作（Modify Operations）： 执行实际的元数据修改，例如通过 xfs_trans_ijoin() 将 inode 加入事务，或通过 xfs_trans_bjoin() 将 buffer 加入事务。所有修改先发生在内存中。
4. 提交事务（Transaction Commit）： 调用 xfs_trans_commit() 将事务标记为提交状态。此时，事务内的所有修改被封装成一个日志项（Log Item）。
5. 写入日志（Log Write）： 调用 xfs_log_commit() 将日志项写入日志设备的环形缓冲区（Log Buffer）。这是关键的持久化步骤，确保崩溃后可恢复。
6. 日志完成（Log Completion）： 日志写入完成后，事务被视为已持久化。此时可以释放锁，并将修改应用到文件系统的实际元数据区域（延迟应用）。

3.3 日志的提交与检查点（Checkpoint）

日志提交（Log Commit）和检查点（Checkpoint）是 XFS 日志管理的两个核心概念，它们共同决定了日志的写入频率、空间回收以及恢复速度。

3.3.1 日志提交（Log Commit）

当日志项被写入日志缓冲区后，XFS 会通过 xfs_log_force() 或 xfs_log_force_lsn() 强制将缓冲区内容刷写到磁盘上的日志区域。这个过程称为日志提交。提交操作会生成一个日志序列号（Log Sequence Number, LSN），用于标识日志中的位置。

日志提交的触发条件包括：

• 事务提交： 每个事务提交时，其日志项必须被持久化。
• 同步操作： 如 fsync()、sync() 系统调用。
• 日志缓冲区满： 当日志缓冲区达到阈值时，内核会强制提交。
• 检查点触发： 检查点操作需要确保日志项已提交。

3.3.2 检查点（Checkpoint）

检查点是将日志中已提交的事务所对应的元数据修改，从日志区域实际写入到文件系统的主元数据区域（如 inode table、AG headers）的过程。检查点完成后，对应的日志空间可以被回收重用。

检查点的工作流程如下：

检查点的触发时机包括：

• 日志空间不足： 当日志使用率达到阈值（如 85%）时，内核会主动触发检查点以回收空间。
• 周期性检查点： 内核线程 xfslogd 会定期执行检查点操作。
• 用户触发： 通过 sync() 或 fsync() 间接触发。
• 卸载文件系统： 卸载前必须完成所有检查点。

3.3.3 日志提交与检查点的关系

日志提交和检查点是两个独立但协作的过程：