操作系统中的文件系统日志（Journaling File System）

1. 问题背景

文件系统需要保证数据的一致性：当发生写操作（如创建文件、修改数据）时，若系统突然崩溃（如断电），文件系统可能处于不一致状态（例如元数据更新了，但数据未写入）。传统的文件系统（如早期的EXT2）依赖fsck（文件系统检查）在启动时修复错误，但修复耗时随磁盘容量增长而增加。

日志文件系统的核心思想：通过记录写操作的“日志”（Journal），在崩溃后快速恢复一致性，避免全盘扫描。

2. 日志的三种模式

日志文件系统（如EXT3/EXT4、NTFS）通常提供三种日志模式，权衡性能与安全性：

1. Writeback（回写）模式

   • 仅记录元数据变更：日志中只保存文件元数据（如inode、目录结构）的修改计划。
   • 风险：若数据本身未写入磁盘就崩溃，文件内容可能错误，但元数据一致性可保证。
   • 性能最高：因数据写入无需日志开销。

2. Ordered（有序）模式

   • 默认模式（如EXT4）：先写数据到磁盘，再记录元数据变更日志。
   • 保证：元数据更新前，相关数据已落盘，避免文件数据与元信息不一致。
   • 示例：追加写文件时，先写入数据块，再记录inode更新的日志。

3. Data（数据）模式

   • 元数据和数据均记录日志：所有变更（包括文件内容）先写入日志区域，再写回实际位置。
   • 安全性最高：崩溃后可从日志恢复数据和元数据。
   • 性能最低：数据需写入两次（日志区+实际位置）。

3. 日志的工作流程

以Ordered模式为例，详细说明一次写操作的步骤：

1. 阶段1：数据写入

   • 应用程序请求修改文件数据。
   • 文件系统先将数据写入磁盘的实际数据块（绕过日志）。
   • 注意：此时元数据（如文件大小、位置）尚未更新。

2. 阶段2：日志记录

   • 文件系统将本次操作的元数据变更计划打包成一个“事务”（Transaction），写入日志区域（固定大小的循环缓冲区）。
   • 日志条目包含：操作类型（如“删除文件A”）、涉及的元数据块编号、变更前的状态等。

3. 阶段3：提交日志

   • 在日志中标记该事务为“已提交”（Commit Record），表示日志记录完整，可执行实际更新。

4. 阶段4：实际更新元数据

   • 根据日志内容，将元数据写入磁盘的实际位置（如更新inode表）。

5. 阶段5：清理日志

   • 事务完成后，在日志中标记该事务为“已完成”，允许覆盖日志空间。

4. 崩溃恢复机制

系统崩溃后重启时，文件系统检查日志区域：

• case1：日志中存在未提交的事务
  • 说明事务未完成，直接丢弃该日志条目（因实际元数据未更新）。
• case2：日志中存在已提交但未完成的事务
  • 重新执行该事务（将日志中的元数据变更写回实际位置），确保一致性。

优势：只需扫描日志区域（通常几MB），而非整个磁盘，恢复时间从分钟级降至秒级。

5. 日志的存储方式

• 专用日志设备：日志可存储在单独磁盘或NVRAM（非易失内存），避免磁头寻道开销。
• 文件系统内部日志：更常见的方式是在磁盘划分固定区域（如EXT4的.journal文件）。

6. 总结

日志文件系统通过“预写日志”将随机写转化为顺序写，提升崩溃恢复效率。三种模式在数据安全与性能间灵活权衡，适用于不同场景（如数据库常用Data模式，通用系统常用Ordered模式）。