问题标签 [fsync]

我有一些大致像这样的 Python 代码，使用一些您可能拥有或没有的库：

基本上，我正在启动一个子进程，该子进程应该为我下载一些数据并将其打印到标准输出。我将该数据重定向到一个文件，然后，一旦子进程调用返回，我将关闭该文件的句柄，然后将该文件复制到其他地方。

我观察到，有时，我期望的数据的尾部没有进入副本。现在，可能bcftools只是偶尔不写入该数据，但我担心我可能会做一些不安全的事情，并且在subprocess.check_call()返回后以某种方式访问​​文件，但在子进程写入标准输出的数据之前放到我可以看到的磁盘上。

查看 C 标准（因为 bcftools 是用 C/C++ 实现的），看起来当程序正常退出时，所有打开的流（包括标准输出）都被刷新和关闭。请参阅此处[lib.support.start.term]的部分，描述 的行为，它在返回时被隐式调用：exit()main()

--接下来，所有打开的带有未写入缓冲数据的 C 流（由 中声明的函数签名介导）被刷新，所有打开的 C 流都被关闭，所有通过调用 tmp-file() 创建的文件都被删除。30)

--最后，控制权返回到宿主环境。如果状态为零或 EXIT_SUCCESS，则返回状态成功终止的实现定义形式。如果状态为 EXIT_FAILURE，则返回状态不成功终止的实现定义形式。否则返回的状态是 implementation-defined.31)

因此，在子进程退出之前，它会关闭（并因此刷新）标准输出。

但是，Linux的手册页close(2)指出，关闭文件描述符并不一定保证写入它的任何数据都已实际写入磁盘：

成功关闭并不能保证数据已成功保存到磁盘，因为内核延迟写入。文件系统在流关闭时刷新缓冲区并不常见。如果您需要确保数据是物理存储的，请使用 fsync(2)。（此时这将取决于磁盘硬件。）

因此，看起来，当进程退出时，其标准输出流被刷新，但如果该流实际上由指向磁盘上文件的文件描述符支持，则不能保证写入磁盘已完成。我怀疑这可能就是这里发生的事情。

所以，我的实际问题：

1. 我对规格的阅读是否正确？在其重定向的标准输出在磁盘上可用之前，子进程是否可以在其父进程看来已终止？

2. 是否有可能以某种方式等待子进程写入文件的所有数据实际上已由操作系统同步到磁盘？

3. 我应该在父进程的文件对象副本上调用flush()还是某个 Python 版本？fsync()这可以强制子进程写入相同的文件描述符以提交到磁盘吗？

我想我能够dnf --installroot=...使用LD_PRELOAD=/usr/lib64/nosync/nosync.so. 但这似乎对debootstrap. 我认为它仍然使用fsync()，只需查看性能/磁盘活动（特别是“拆包”行）。还有其他方法吗？

从 man fsync(2) 开始，它将同步文件的元数据，我认为这是 stat 中的列表。文件的 xattr 是怎么回事？它属于元数据吗？我们做了一个测试，写一个文件，设置6个xattr，然后做fsync，然后改变1个xattr值，再做一次fsync（使用0.2s）。我们认为第二个 fsync 应该很快，但事实并非如此（使用 0.16s）。

使用引导库复制文件时出现问题。复制文件后，有时文件大小为 0kb。

这是我的代码：

我只是想知道我应该打电话sync()，fsync()还是 fflush()为了那个？

据我所知，只有基于流的 i/o 需要fflush()保证文件写入，但是我找不到关于boost::filesystem::copy.

考虑以下场景：

• 我们在 docker 容器中使用 DBMS；
• DBMS 写入 WAL 或 REDO 日志，并在事务提交时调用 fsync；
• fsync 指示客户操作系统将“脏”IO 缓冲区刷新到磁盘；
• 数据保留在主机操作系统的 IO 缓冲区中；
• 主机系统崩溃；

有可能的情况吗？

我有一个包含数千个文件的应用程序正在更新。应用程序需要定期将更改提交到磁盘，目前我正在调用fdatasync()，这需要大量时间（分钟）。[减少正在写入的文件数量不是我的选择。]

同时，我注意到如果我从命令行运行sync命令，它会明显更快地返回。从文档看来，它似乎可以保证所有挂起的写入都到达磁盘。

问题是：sync()系统调用是否提供与多次调用相同（或更强）的持久性保证fdatasync()？如果没有，有没有办法fsync()一次调用多个文件描述符？

对文件调用 fsync() 时，文件会损坏吗？

例如，假设我的文件分布到磁盘块：

假设我想将整个文件内容更改为小写（以非常低效的方式）。所以我寻求文件的位置 1 将“H”更改为“h”，然后位置 8 将“W”更改为“w”。然后我调用fsync()文件。该文件分布在两个磁盘块上。

1. 写入的顺序是否得到维护？
2. fsync() 操作在磁盘上是原子的吗？

当我发出时write()，我的数据会进入一些内核空间缓冲区。对物理层的实际提交（“phy-commit”）（可能）被推迟，直到……（直到发生什么事件？）

close()当我为文件描述符发出 a 时，然后

如果 [...]，则释放与打开文件描述相关的资源

这是否意味着释放（释放）那些包含我的数据的内核缓冲区？这些缓冲区中包含的宝贵数据会怎样？会迷路？

如何防止这种损失？

通过fsync()？它请求一个明确的 phy-commit。我想要么立即（同步调用），要么只推迟“短时间”并排队等待后续操作，至少是破坏性操作。

但我不太想要立即或紧急的 phy-commit。只是（保留我的数据并且）不要忘记稍后再做 phy-commit。

来自man fclose：

fclose() 函数 [...] 关闭底层文件描述符。
...
fclose() 仅刷新 C 库提供的用户空间缓冲区。为确保数据物理存储在磁盘上，内核缓冲区也必须刷新，例如使用 sync(2) 或 fsync(2)。

它可能暗示 thatfsync不必在（或, 其中包含 a ）之前 ，但可以（甚至必须）在它之后。所以不会是非常具有破坏性...closefclosecloseclose()

我正在尝试克隆 tensorflow/models 存储库。我通过 ssh 连接到远程机器。我尝试了很多解决问题的建议，但没有一个对我有用。

我正在使用 cv::imwrite 将图像写入磁盘，但我需要确保在该函数返回后文件同步到磁盘。有没有办法保证？

为了使用系统调用 fsync，我需要一个文件描述符，在使用 cv::imwrite 时我无法访问它。有什么解决方法吗？