c - 关闭文件描述符时如何防止数据丢失？

Question

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

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

If [...], the resources associated with the open file description are freed

这是否意味着释放(释放)那些包含我的数据的内核缓冲区？这些缓冲区中包含的宝贵数据会怎样？会丢失吗？

如何防止这种损失？

通过 fsync()？它请求一个显式的物理提交。我想要么立即(同步调用)要么仅“短时间”延迟并排队等待后续操作，至少是破坏性操作。

但我不太想要立即或紧急的物理提交。只是(保留我的数据并且)不要忘记稍后进行 phy-commit。

来自 man fclose:

The fclose() function [...] closes the underlying file descriptor.
...
fclose() flushes only the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).

这可能表明 fsync 不必先于 close(或 fclose，它包含一个 close)，但可以(甚至必须)跟在它之后。所以 close() 不会有太大的破坏性......

Answer 1

Does it mean releasing (freeing) those kernel buffers which contained my data? What will happen to my precious data, contained in those buffers? Will be lost?

没有。在将数据写入底层文件之前，内核缓冲区不会被释放。因此，不会有任何数据丢失(除非确实出现问题 - 例如系统断电)。该数据是否会立即写入物理文件是另一个问题。它可能取决于文件系统(可能正在缓冲)和/或任何硬件缓存。就您的用户程序而言，成功的 close() 调用可视为成功写入文件。

It may suggest that fsync does not have to precede close (or fclose, which contains a close), but can (even have to) come after it. So the close() cannot be very destructive...

调用 close() 后，POSIX 未指定文件描述符的状态(无论 close() 是否成功)。因此，不允许在调用 close() 之后使用 fsync(fd); 。请参阅:POSIX/UNIX: How to reliably close a file descriptor .

不，这并不表明 close() 具有破坏性。它表明 C 库可能在用户中进行自己的缓冲，并建议使用 fsync() 将其刷新到内核(现在，我们处于与之前相同的位置)。