小编Nat*_*dge的帖子

在没有 fsync() 的情况下替换现有文件是否“损坏”?

在 Linux 的mount(2)手册页中,我注意到以下摘录:

许多损坏的应用程序在通过模式替换现有文件时不使用 fsync(),例如

fd = open("foo.new")/write(fd,...)/close(fd)/ rename("foo.new", "foo")
Run Code Online (Sandbox Code Playgroud)

或者更糟

fd = open("foo", O_TRUNC)/write(fd,...)/close(fd).
Run Code Online (Sandbox Code Playgroud)

如果启用了 auto_da_alloc,ext4 将检测替换通过重命名和替换通过截断模式并强制分配任何延迟分配块,以便在下一次日志提交时,在默认的 data=ordered 模式下,在提交 rename() 操作之前,新文件被强制写入磁盘。这提供了与 ext3 大致相同级别的保证,并避免了在延迟分配块被强制写入磁盘之前系统崩溃时可能发生的“零长度”问题。

这段代码在什么意义上被“破坏”了?他们是说这段代码是非法的还是不符合标准(POSIX 等)?

显然fsync(),对于担心系统崩溃会发生什么的人来说,这可能是一个好主意。但是假设系统不会崩溃,那么示例代码的两个版本(没有fsync())是否都做正确的事情?

io synchronization files failure-resistance

4
推荐指数
1
解决办法
551
查看次数

标签 统计

failure-resistance ×1

files ×1

io ×1

synchronization ×1