ext4下使用O_DIRECT/O_SYNC打开文件时fsync()的行为是怎样的？

基于Linux 5.8版本ext4的原生实现，两种文件打开模式下的fsync执行逻辑如下：

仅以O_DIRECT标志打开文件，执行write()后调用fsync()的流程 #

与XFS在O_DIRECT写场景下，主动将元数据同步绑定到write()返回流程的逻辑不同，Linux 5.8的ext4在O_DIRECT写入路径下，遇到文件大小变更、块映射更新这类元数据修改时，只会把inode标记为脏状态，不会在write()返回时主动触发元数据持久化。此时调用fsync()会依次执行以下动作：

• 遍历扫描当前inode关联的所有未持久化对象：包括脏的inode元数据字段（如文件大小、块计数）、extent树映射节点、待写回的块缓存页
• 等待与该inode绑定的未提交日志事务完成落盘：ext4默认使用日志保护机制，元数据变更会先写入日志区，这一步会确保关联日志事务完整持久到块设备，避免元数据出现交叉不一致
• 向底层块设备发送缓存刷新指令，将设备写缓存中所有与该文件相关的用户数据、元数据强制写入非易失存储

注：该场景下的fsync是保障数据一致性的必需操作，如果跳过fsync，ext4的后台writeback线程可能延迟数秒甚至更久才触发元数据落盘，断电场景下会出现文件大小、块映射信息丢失的问题，这也是MySQL O_DIRECT_NO_FSYNC模式在Linux 5.8版本ext4上存在潜在一致性风险的核心原因。

以O_DIRECT | O_SYNC标志打开文件，操作后调用fsync()的实际行为 #

首先需要明确O_SYNC在Linux 5.8版本ext4中的语义：当文件携带O_SYNC标志时，每一次write()操作返回前，都会强制完成所有对应用户数据、关联元数据、对应日志事务的持久化，语义强度高于单独的O_DIRECT。
此时再调用fsync()的执行逻辑非常简单：

• 同样进入ext4的fsync系统调用入口，执行标准的全流程检查
• 由于此前的write流程已经把所有相关数据、元数据、日志事务同步落盘，检查环节会识别出当前inode没有任何待同步的脏对象、没有未提交的关联日志事务
• 最终仅完成合规性校验，最多补一次底层块设备的缓存刷新操作，没有实际的持久化写入开销，也不存在同步遗漏
  从实现逻辑上看，O_SYNC提供的持久化保证已经完全覆盖了单文件fsync的所有能力，后续的fsync调用属于冗余操作，不会带来额外的数据一致性收益。

内容的提问来源于stack exchange，提问作者Tim He