为什么关闭文件在覆盖文件时会等待同步，而在创建文件时则不会？

Question 1

这听起来像是在提醒O_PONIES我们最近刚刚度过了 11 岁生日的那场惨败。

在 ext4 出现之前，ext3 已经获得了在断电时保持稳定的声誉。它很少损坏，也很少丢失文件中的数据。然后，ext4添加了数据块的延迟分配，这意味着它甚至不会尝试立即将文件数据写入磁盘。通常，只要数据在某个时刻到达那里，这就不成问题，而对于临时文件，可能根本不需要将数据写入磁盘。

但ext4确实写了元数据更改，并记录文件发生了某些变化。现在，如果系统崩溃，文件会被标记为已截断，但此后的写入不会存储在磁盘上（因为没有为它们分配块）。因此，在 ext4 上，您经常会看到最近修改的文件在崩溃后被截断为零长度。

当然，这并不完全是大多数用户想要的，但有人认为，如此关心其数据的应用程序应该调用fsync()，并且如果他们确实关心重命名，它们也应该fsync()（或至少fdatasync()）包含目录。不过，几乎没有人这样做，部分原因是在 ext3 上，同步fsync()了整个磁盘，可能包括大量不相关的数据。（或者尽可能接近整个磁盘，差异无论如何都无关紧要。）

现在，一方面，ext3 的性能较差，fsync()另一方面，ext4 要求fsync()不丢失文件。考虑到大多数应用程序都愿意实现特定于文件系统的行为，甚至比fsync()在正确的时刻进行调用的僵化舞蹈更不关心，这不是一个好的情况。显然，要弄清楚文件系统是否存在并不容易曾是首先安装为 ext3 或 ext4。

最后，ext4 开发人员对最常见的看似危急的情况进行了一些更改

在另一个文件之上重命名一个文件。在正在运行的系统上，这是一个原子更新，通常用于放置文件的新版本。
覆盖现有文件（您的情况）。这在运行的系统上不是原子的，但通常意味着应用程序希望替换文件，而不是截断文件。如果覆盖失败，您将丢失旧版文件的内容，因此这与创建一个全新的文件有点不同，后者断电只会丢失最新的数据。

据我所知，XFS 在崩溃后甚至在 ext4 之前也表现出类似的零长度文件。不过，我从来没有遵循这一点，所以我不知道他们会做什么样的修复。

请参阅 LWN 上的这篇文章，其中提到了修复：ext4 和数据丢失（2009 年 3 月）

_{当然，当时还有其他关于此的文章，但我不确定链接到它们是否有用，因为这主要是一个相互指责的问题。}

Answer

这听起来像是在提醒O_PONIES我们最近刚刚度过了 11 岁生日的那场惨败。