filesystems - 安全有效的方式来修改POSIX系统上的多个文件？

Question

我一直在关注关于EXT4上“错误”的讨论，如果使用“创建临时文件，写入临时文件，将临时文件重命名为目标文件”过程，该文件将导致崩溃时文件归零。 POSIX说除非调用fsync()，否则不能确保数据已刷新到硬盘。

显然在做:

0) get the file contents (read it or make it somehow)
1) open original file and truncate it
2) write new contents
3) close file

即使使用fsync()也不是很好，因为计算机可能在2)或fsync()期间崩溃，并且最终导致部分写入文件。

通常认为这是非常安全的:

0) get the file contents (read it or make it somehow)
1) open temp file
2) write contents to temp file
3) close temp file
4) rename temp file to original file

不幸的是，事实并非如此。为了使其在EXT4上安全，您需要执行以下操作:

0) get the file contents (read it or make it somehow)
1) open temp file
2) write contents to temp file
3) fsync()
4) close temp file
5) rename temp file to original file

这将是安全的，并且在崩溃时，您应该具有新的文件内容，或者具有旧的，永不为零的内容或部分内容。但是，如果应用程序使用大量文件，则每次写入后的fsync()都会很慢。

所以我的问题是，在需要fsync()以确保更改已保存到磁盘的系统上，如何有效地修改多个文件？我的意思是修改很多文件，就像修改成千上万个文件一样。修改两个文件并在每个文件之后执行fsync()可能还不错，但是当修改多个文件时，fsync()确实会减慢速度。

编辑:将fsync()关闭临时文件更改为当前顺序，增加了对编写许多文件的重视。

Answer 1

简短的答案是:在应用程序层中解决此问题是错误的。 EXT4必须确保在关闭文件后，应及时写入数据。现在，EXT4“优化”了此编写，以能够收集更多的写请求并将它们一次性爆发。

问题很明显:无论您做什么，都无法确保数据在磁盘上结束。手动调用fdisk()只会使情况变得更糟:您基本上会妨碍EXT4的优化，从而降低了整个系统的速度。

OTOH，EXT4具有所有必要的信息，可以在需要将数据写到磁盘时进行有根据的猜测。在这种情况下，我将临时文件重命名为现有文件的名称。对于EXT4，这意味着它必须推迟重命名(以便崩溃后原始文件的数据保持不变)或必须立即刷新。由于它不能推迟重命名(下一个过程可能要查看新数据)，因此隐式重命名意味着刷新，并且刷新必须在FS层而不是应用程序层上进行。

EXT4可能会创建文件系统的虚拟副本，其中包含尚未更改磁盘的更改(尚未)。但这并不影响最终目标:应用程序无法确定FS会进行哪些优化，因此FS必须确保其能够正常工作。

在这种情况下，无情的优化已经走得太远，破坏了结果。黄金法则:优化绝不能改变最终结果。如果您无法保持这一点，那么就不能进行优化。

只要Tso认为拥有一个快速的FS而不是运行正常的FS更重要，我建议不要升级到EXT4并关闭所有关于此错误的报告是“Tso设计的”。

[编辑]对此有更多的想法。您可以使用数据库而不是文件。让我们暂时忽略资源浪费。谁能保证数据库使用的文件不会因崩溃而损坏？大概。数据库可以写数据并每分钟左右调用fsync()。但是然后，您可以执行以下操作:

while True; do sync ; sleep 60 ; done

再次，FS中的错误使这种情况在每种情况下均无法正常工作。否则，人们不会被这个错误所困扰。

您可以使用Windows注册表之类的后台配置守护程序。守护程序会将所有配置写入一个大文件。将所有内容写完后，可以调用fsync()。问题已解决...适用于您的配置。现在，您需要对应用程序编写的其他所有内容执行相同的操作:文本文档，图像等。我的意思是几乎所有Unix进程都会创建一个文件。这是整个Unix理念的基础!

显然，这不是一条可行的道路。因此答案仍然存在:您这边没有解决方案。继续困扰Tso和其他FS开发人员，直到他们修复错误为止。