Is rename() without fsync() safe?
在不先呼叫
我希望路径始终指向完整的文件。我主要关心ext4。rename()是否承诺在将来的所有Linux内核版本中都是安全的?
python中的用法示例:
1 2 3 4 5 6 7 8 9 | def store_atomically(path, data): tmppath = path +".tmp" output = open(tmppath,"wb") output.write(data) output.flush() os.fsync(output.fileno()) # The needed fsync(). output.close() os.rename(tmppath, path) |
不。
看看libeatmydata,这个演示文稿:
吃我的数据:每个人如何得到文件IO错误http://www.oscon.com/oscon2008/public/schedule/detail/3172
来自MySQL的Stewart Smith。
如果它脱机/不再可用,我会保留一份副本:
- 这里的视频
- 演示文稿幻灯片(联机版本的幻灯片)
从ext4文档:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | When mounting an ext4 filesystem, the following option are accepted: (*) == default auto_da_alloc(*) Many broken applications don't use fsync() when noauto_da_alloc replacing existing files via patterns such as fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new","foo"), or worse yet, fd = open("foo", O_TRUNC)/write(fd,..)/close(fd). If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is committed. This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk. |
从"中断的应用程序"一词来看,它无疑被ext4开发人员视为不好的实践,但在实践中,它被广泛使用,以致于在ext4本身中进行了修补。
所以如果你的使用符合模式,你应该是安全的。
如果没有,我建议你进一步调查,而不是在这里和那里插入
另一方面,重命名前刷新是在非日志文件系统上进行替换的正确方法。也许这就是ext4最初期望从程序中得到这种行为的原因,后来添加了
您可以在这里阅读有关ext4问题的更多信息。
如果您只关心ext4而不关心ext3,那么我建议在执行重命名之前对新文件使用fsync。在没有很长延迟的情况下,ext4上的fsync性能似乎比ext3上的要好得多。或者写回是默认模式(至少在我的Linux系统上)。
如果只关心文件是否完整,而不关心在目录中命名哪个文件,那么只需要fsync新文件。也不需要同步目录,因为它将指向包含完整数据的新文件或旧文件。