没有 fsync() 的 rename() 是否安全？

问题描述：

rename(tmppath, path)如果不先打电话就直接拨打电话是否安全fsync(tmppath_fd)？

我希望路径始终指向一个完整的文件。我主要关心Ext4。rename() 是否保证在所有未来的 Linux 内核版本中都是安全的？

Python 中的使用示例：

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)

解决方案 1：

不。

查看 libeatmydata 和此演示文稿：

吃掉我的数据：每个人都犯了文件 IO 错误

http://www.oscon.com/oscon2008/public/schedule/detail/3172

由 MySql 的 Stewart Smith 撰写。

如果它处于离线状态/不再可用，我会保留它的副本：

• 视频在这里

• 演示幻灯片（在线版幻灯片）

解决方案 2：

来自ext4 文档：

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 造成重大性能影响（阅读）。

另一方面，在非日志文件系统上，重命名前刷新是执行替换的正确方法。也许这就是为什么 ext4 最初期望程序有这种行为，auto_da_alloc后来添加了该选项作为修复。此外，这个针对写回（非日志）模式的 ext3 补丁试图通过在重命名时异步刷新来帮助粗心的程序，以降低数据丢失的可能性。

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

解决方案 3：

如果您只关心 ext4 而不关心 ext3，那么我建议在重命名之前对新文件使用 fsync。ext4 上的 fsync 性能似乎比 ext3 上的好得多，而且没有很长的延迟。或者可能是因为 writeback 是默认模式（至少在我的 Linux 系统上）。

如果您只关心文件是否完整，而不关心目录中哪个文件的名称，则只需 fsync 新文件即可。无需 fsync 目录，因为它将指向包含完整数据的新文件或旧文件。