关于linux:没有fsync()的rename()安全吗?

Is rename() without fsync() safe?

在不先呼叫fsync(tmppath_fd)的情况下呼叫rename(tmppath, path)安全吗?

我希望路径始终指向完整的文件。我主要关心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本身中进行了修补。

所以如果你的使用符合模式,你应该是安全的。

如果没有,我建议你进一步调查,而不是在这里和那里插入fsync,只是为了安全。这可能不是一个好主意,因为fsync可能是ext3(read)的主要性能问题。

另一方面,重命名前刷新是在非日志文件系统上进行替换的正确方法。也许这就是ext4最初期望从程序中得到这种行为的原因,后来添加了auto_da_alloc选项作为修复方法。另外,这个用于写回(非日志)模式的ext3补丁试图通过在重命名时异步刷新来帮助粗心的程序,以降低数据丢失的可能性。

您可以在这里阅读有关ext4问题的更多信息。


如果您只关心ext4而不关心ext3,那么我建议在执行重命名之前对新文件使用fsync。在没有很长延迟的情况下,ext4上的fsync性能似乎比ext3上的要好得多。或者写回是默认模式(至少在我的Linux系统上)。

如果只关心文件是否完整,而不关心在目录中命名哪个文件,那么只需要fsync新文件。也不需要同步目录,因为它将指向包含完整数据的新文件或旧文件。