问题与使用场景
题目包含三个不同保证。原子可见性要求重新打开目标路径的读者只能看到一个完整版本。崩溃持久性要求已确认版本重启后仍可访问。写者隔离决定两个更新竞争时谁获胜。单独一次 rename() 在文件系统契约内只解决第一项。
假设使用正确实现 fsync() 和同文件系统原子替换的本地 Linux 文件系统，写者已串行化，以前确认的版本也由同一协议写入。64 KiB 是面试假设。网络文件系统、谎报缓存刷新的硬件、多文件事务和恶意目录修改需要单独契约。
适用对象包括配置快照、本地代理状态、检查点清单和编辑器保存。状态跨多个文件或需要并发事务时，嵌入式数据库或日志通常比继续手写协议更可靠。
面试官考察什么
第一个信号是能否区分 write() 成功、rename() 原子性和持久提交。Linux 文档说明 write() 可能短写，成功返回也不证明数据已落盘。fsync(file) 刷新文件数据及相关元数据，却不一定持久化目录项，最后这条边需要 fsync(parent_directory)。
第二个信号是顺序：新字节必须先持久化，命名空间才能把目标名指向它；目录项随后必须持久化，调用者才能收到成功。漏掉或颠倒屏障都会留下崩溃窗口。
第三个信号是诚实的失败语义。fsync() 可能延迟报告 EIO、ENOSPC 或配额错误。最终目录同步失败时，rename 可能已经可见，但持久性未知，接口应返回“不确定”，不能声称成功或保证回滚。
回答前的澄清问题
- 原子是否覆盖进程退出和主机断电？ 进程退出不会清空内核页缓存；题目要求主机崩溃持久性，因此必须同步。
- 部署文件系统的契约是什么？ NFS、FUSE、overlay 和特殊存储栈可能不同，必须验证真实环境。
- 是否有多个写者？ 基础方案串行写者；唯一临时名只防文件名冲突，不防后写覆盖。
- 是否同时更新多个文件？ 一次 rename 只能提交一个路径替换，多文件不变量需要代目录、日志或数据库。
- 旧文件描述符能否继续读旧版本？ 可以；rename 改变目录映射，已打开描述符仍指向旧 inode。
- 什么内容才有效？ 发布前校验序列化、schema、校验和与版本；文件系统原子性不能修复完整但错误的载荷。
30 秒回答框架
“我先区分原子可见性和持久性。打开父目录，在同一目录用排他创建生成唯一临时文件，循环写完全部字节，设置必要元数据，然后 fsync 临时文件。关闭后用 rename 原子替换目标，再 fsync 父目录，最后才返回成功。文件同步保证新 inode 内容持久，rename 发布一个完整版本，目录同步保证名字到 inode 的映射持久。我会串行写者，把包括最终目录同步失败在内的系统调用错误返回为非成功或不确定状态，启动时清理孤儿临时文件，并在每个边界做断电测试，而不是把杀进程当成持久性证明。”
分步深入分析
调用者视角的提交点是父目录 fsync 成功。协议如下：
durableReplace(parentDir, targetName, bytes):
dirfd = open(parentDir, read-only | directory | close-on-exec)
tmpName = uniqueSiblingName(targetName)
tmpfd = openat(dirfd, tmpName, create | exclusive | write-only | close-on-exec, mode)
writeAll(tmpfd, bytes) // 重试 EINTR，短写后推进偏移
setRequiredMetadata(tmpfd) // 权限和所有者属于契约时先设置
fsync(tmpfd) // 检查延迟 I/O 和分配错误
close(tmpfd) // 检查返回值
renameat(dirfd, tmpName, dirfd, targetName)
fsync(dirfd) // 持久化命名空间变化
close(dirfd)
return committed临时文件必须与目标同目录，使 rename 留在同一文件系统，避免 EXDEV 后退化为非原子复制。使用排他创建和不可预测的进程内后缀，不跟随攻击者预建的符号链接。权限等必需元数据应在文件同步前设置。
即使是普通文件也要实现 writeAll。正返回值小于请求长度就是短写，应推进缓冲区继续写；只在合适条件下重试中断。成功 write() 只表示内核接收数据，close() 也不是提交屏障，延迟错误可能在 fsync() 才出现。
随后同步临时文件。fsync 刷新修改的数据和 inode 元数据，并等待设备报告完成。fdatasync 可省略与后续读取无关的元数据，但仍要持久化文件大小等必要元数据。通用面试回答优先用更易审计的 fsync，除非实测和文件系统契约支持优化。
文件同步成功后才执行 rename。目标已存在时，Linux 保证其他进程打开目标不会观察到路径缺失。已打开旧文件的读者可读完旧 inode，之后打开的读者解析到新 inode；两者都是完整版本。
rename 修改的是目录元数据。文件同步不一定持久化目录项，因此 rename 后必须同步父目录。正确顺序构成证明：
新内容持久
-> 目标名原子指向新 inode
-> 目标名映射持久
-> 才能向调用者确认成功rename 前崩溃可能留下旧目标和孤儿临时文件。rename 后、目录同步前，新目标可能当前可见，但重启后是否可达尚无承诺。目录同步成功后，已同步内容和目录映射才组成提交版本。恢复过程只清理能确认归属且符合命名规则的过期临时文件，不能因为上次返回错误就删除目标。
错误状态不能只有布尔值。rename 前失败是 not_committed，旧目标仍是权威版本。rename 后目录同步失败是 indeterminate：新文件可能可见，也可能无法承受崩溃。返回错误并保留诊断，恢复时检查代号或校验和。盲目写回旧值会再制造一次未提交变化，还可能覆盖更晚的写者。
多个写者可用所有写者都遵守的锁包住完整读改写流程，或携带预期代号拒绝旧更新。唯一临时名只隔离暂存。没有串行化时，两次 rename 各自原子，后者仍会静默覆盖前者。多个关联文件应发布一个不可变代目录，再持久切换单一清单指针，或改用日志、SQLite。
严格模式每次提交至少支付文件与目录两个刷盘屏障。若只需原子可见性，可提供名称明确的宽松模式：临时文件加 rename，但允许断电丢失最新版。高频更新可把多项逻辑修改合并进一次日志提交，或使用支持 group commit 的数据库；不能为了跑分快而暗中削弱契约。
测试要覆盖短写、EINTR、ENOSPC、文件同步 EIO、文件同步前后崩溃、rename 前中后崩溃、目录同步失败。重启后断言目标可解析，只是最后确认版本或允许出现的未确认新版本，绝不能是字节混合；每个已确认代都必须存活。SIGKILL 只能测试清理和描述符行为，受控 VM 或存储崩溃才能覆盖易失缓存丢失。
高质量示例回答
“我先定义三个契约：读者只看到完整版本、已确认更新承受主机崩溃、写者已串行化；当前目标也假定由同一协议提交。
我打开父目录，在目标旁排他创建唯一临时文件。循环处理短写，设置必要权限，对临时文件调用并检查 fsync，再关闭。然后用 rename 替换目标。这是原子可见边界：现有读者可继续使用旧 inode，新打开得到完整新 inode。
rename 还不是持久提交。它修改了目录项，而文件同步不一定持久化目录项。因此我同步父目录，只有成功后才返回成功。rename 前崩溃保留旧目标和可能的临时文件；rename 后、目录同步前失败属于不确定状态，应返回错误并在恢复时检查代号，不能承诺回滚。
我会注入短写和每个系统调用错误，并在每个边界让 VM 崩溃。判定条件是目标始终为有效旧代或新代，绝无撕裂混合，而且每个已确认代重启后仍存在。需要并发写者或多文件事务时，我增加代号检查与锁，或改用日志/数据库，不会声称 rename 能解决这些问题。”
常见错误
- 原地覆盖目标 → 崩溃会暴露截断或混合内容 → 完整暂存同目录文件后再 rename。
- 假设一次
write()写完 → 短写会截断暂存文件 → 循环到全部完成或出错。 - 临时文件未同步就 rename → 持久名字可能指向未完整落盘的数据 → 先同步新 inode。
- 把 rename 当持久提交 → 原子可见不代表目录项落盘 → rename 后同步父目录。
- 临时目录位于另一挂载点 → rename 返回
EXDEV或退化为复制 → 在目标目录创建临时文件。 - 忽略
fsync错误 → 延迟存储失败变成假成功 → 传播非成功或不确定结果。 - 只用
SIGKILL测试 → 内核缓存仍存活 → 增加受控主机或存储崩溃。 - 让多个写者竞争 → 各自原子仍会丢失一个版本 → 串行化或比较预期代号。
追问与回答
追问 1：为什么 fsync(temp) 还不够？
它持久化临时 inode 的内容和相关元数据。目标路径属于目录项；rename 修改映射后，Linux 明确说明文件同步不一定持久化包含它的目录，因此确认前还要同步父目录。
追问 2：其他进程已打开目标时，rename 仍然原子吗？
路径查找的替换是原子的。旧描述符继续指向旧 inode，新打开解析到新 inode。读者若要在多次读取中维持同一代，应保持一个描述符，不要中途重新打开。
追问 3：rename 后目录 fsync 失败，接口返回什么？
返回带“不确定提交状态”的错误。rename 可能已经可见，应用无法证明它会否承受重启。记录预期代和错误，停止确认成功，由恢复流程验证目标；盲目回滚可能破坏更晚更新。
追问 4：fdatasync 能替代 fsync 吗？
平台契约和实测支持时可以。它省略与数据读取无关的元数据，但仍须持久化文件大小等必要信息，也不能省略 rename 后的父目录同步。通用回答使用 fsync 更易审计。
追问 5：如何原子更新三个文件？
三次独立 rename 会暴露混合代。把所有文件写进不可变代目录并持久化，再原子切换并同步一个清单或指针；也可使用日志或嵌入式数据库。读者解析一次代号并在整个操作中保持它。
追问 6：两个写者如何避免丢失更新？
使用所有写者都遵守的锁覆盖完整读改提交过程，或携带预期代号并拒绝陈旧提交。唯一临时名只能防暂存冲突；原子 rename 不比较业务版本，天然允许后写覆盖。