Linux rename原子操作生效条件及并行硬链接创建报错问题咨询

问题根因 #

该现象是Linux内核虚拟文件系统（VFS）层长期存在的已知行为，并非rename原子性承诺失效：

• rename的原子性保证仅约束单个rename系统调用执行前后，目标路径始终对用户可见，要么指向旧文件、要么指向新文件，不存在路径缺失的中间状态。
• 当多个线程同时发起针对同一目标路径的覆盖式rename操作时，内核内部处理目录项（dentry）替换的过程中，会出现极短暂的瞬态窗口：此时路径查询会暂时拿到「负目录项」（标记为不存在的目录项缓存），如果恰好此时link系统调用触发，就会返回ENOENT（无此文件或目录）错误。
• 该行为虽然不符合POSIX规范的语义，但内核开发社区认为修复该问题需要引入的全局锁会严重降低VFS层的并发性能，因此从2.6.32版本至今都保留了该行为。

各变体表现说明 #

覆盖式rename（变体0/1/2）报错原因 #

这类实现会触发内核目录项替换的并发逻辑，因此在原生Linux上会出现瞬态ENOENT错误；WSL2的定制内核修改了VFS层的目录项处理逻辑，规避了该问题，因此不会报错。

非覆盖式实现（变体3/4）正常原因 #

这类实现不会执行覆盖替换操作：如果目标路径已存在，直接返回错误并删除本地临时文件，不会触发目录项替换的并发逻辑，因此不会出现瞬态路径不存在问题。而WSL2中两类变体报错是因为其DrvFs（Windows挂载文件系统）对硬链接、renameat2系统调用的支持不完善，将测试代码移到WSL2原生ext4文件系统下运行即可恢复正常。

解决方案 #

由于测试场景为内容寻址存储，替换前后文件内容完全一致，可以选择以下任意方案解决：

1. 直接使用测试中验证正常的非覆盖式rename变体即可满足业务需求
2. 如果必须使用覆盖式rename，只需要在link调用报错ENOENT时增加有限次重试逻辑即可，该错误为纯瞬态问题，重试即可成功
3. 避免多线程同时操作同一路径，改为单线程写入缓存文件，多线程只读访问

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