问题标签 [fsync]

文件系统或磁盘驱动程序是否支持文件系统修改栅栏的概念，例如 CPU 或共享内存系统中的内存栅栏？

栅栏是分离内存操作的指令，这样在栅栏事件之后的全局可见内存访问直到所有在它之前的访问才可检测到。

这种功能是否可以有效地用于文件内容修改（和目录修改）？当然，一个简单的解决方案是等到所有写入都写入稳定存储；但是，这会阻塞应用程序，并且如果需要许多同步点，则可能效率低下。此外，当一个大写（包括许多由栅栏隔开的写）满足完全日志系统上的相同约束时，或者当磁盘驱动程序保证最大写是原子的时，它可能会导致许多小的单独写。

是否可以强制文件系统驱动程序使用文件系统访问栅栏对写入进行排序？有没有探索过这个概念？

精确

问题的上下文不是多个进程以一种随意的方式访问相同的文件，而是一个进程将数据保存在数据库中，这样进程的中断（甚至是计算机崩溃）应该只留下一个修改序列（在两个围栏之间）部分写入。

fsync文档状态

调用 fsync() 不一定确保包含该文件的目录中的条目也已到达磁盘。为此，还需要在目录的文件描述符上显式 fsync()。

我正在尝试使用 Windows 上的 SMB 将目录同步到网络映射驱动器，类似于fsyncLinux 上的操作。

如果目录存储在本地驱动器上，则以下 go 代码片段可以正常工作，但如果目录存储在网络映射文件夹上则失败。

该程序失败

MSDN 声明传入的句柄应该是文件句柄或卷的句柄，但没有提及目录。 https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-flushfilebuffers

并且 FlushFileBuffers 未列为接受目录句柄的函数 https://docs.microsoft.com/en-us/windows/desktop/fileio/obtaining-a-handle-to-a-directory

Invalid Device Request我还注意到网络映射驱动器的 flushfilebuffers 系统调用失败

所以问题是如何在 Windows 上同步目录？还是窗口的缓冲 I/O 与 POSIX 根本不同，当目录中的文件被修改时我们不需要刷新目录？

问题

如何在不需要我的程序等待慢速物理介质（例如 with fsync）的情况下自动更新文件？

我希望操作系统可以“缓冲”RAM中的典型fsync和操作，然后在方便时以正确的顺序rename将它们写入磁盘。

背景

我正在开发在带有ext4文件系统的自定义嵌入式 Linux 环境中运行的软件。该程序定期更新磁盘上的文件。我需要在不牺牲应用程序性能的情况下保持此文件的完整性。

根据我的阅读，安全更新文件的公认做法如下：

1. 创建一个新的临时文件
2. 将数据写入临时文件
3. fsync()临时文件
4. 将临时文件重命名为适当的名称
5. fsync()包含目录

这个过程对我来说很有意义，但在我的特定应用程序中，我想避免阻塞调用fsync(). 我不在乎数据何时写入磁盘，只要文件始终处于有效状态即可。如果文件已过期，那没关系。

到目前为止我学到了什么

似乎已经有相当多的讨论ext4和正确使用fsync. 如果我理解正确，我可能会放弃使用fsyncif auto_da_allocis enabled for my filesystem ( link )，但我不相信这是最好的解决方案。

我正在编写一个 Python 程序，它在 USB 驱动器（实际上是安装的 CircuitPython 设备）上进行各种文件修改。当用户在没有先正确弹出设备的情况下拔出或重置设备时，我想尽量减少出现问题的可能性。

写入文件时，建议在关闭fsync文件之前先处理打开的文件。

如何确保在文件删除和目录创建时进行类似的即时同步？我不介意为此调用操作系统命令。

我对fsync+感到困惑direct IO。

这样的代码很容易理解：

在这种情况下，write()会将数据写入页面缓存，并将fsync所有修改过的页面缓存中引用的数据强制fd写入磁盘设备。

但是如果我们打开一个带有O_DIRECT标志的文件，像这样，

在这种情况下，write()会绕过页面缓存，直接写入磁盘设备。那么怎么fsync办呢，. 引用的页缓存中没有脏页fd。

如果我们打开一个原始设备，会fsync做什么，

在这种情况下，我们打开一个原始设备O_DIRECT，该设备上没有文件系统。在这里做什么sync？

“python 的 file.flush() 到底在做什么？” 说你应该先f.flush()确保os.fsync(f)数据写入磁盘。
此外，“close() 是否暗示 Python 中的 flush()？” 声称f.close()意味着 a flush()。

现在，问题是：我应该这样做

或者，确实f.close()也意味着一个os.fsync()？

这里有Python IO的文档，Python 文件关闭的文档，以及源代码。快速搜索“fsync”没有返回相关信息。

O_DIRECT, O_SYNC, 等标志O_DSYNC可用于在创建描述符（createsyscall）时指定同步/异步IO。但是是否可以将此标志用于不同write（或类似）的系统调用，以使其中一些同步？

背景是开发 DBMS 内核，特别是数据库检查点处理。游戏规则是，我们需要等待文件上未完成的异步 IO 完成，然后再发出 fsync()。

我们部署的当前解决方案是手动计算运行中的异步 IO，等待此计数变为 0，然后再进行 fsyncing 或 FlushFileBuffer-ing。问题是我们是否真的必须这样做，也许内核/文件系统自己会这样做？

有问题的操作系统主要是 Windows 和 Linux，尽管我也很好奇基于 BSD 的操作系统如何处理这些问题。

在 Linux 上，我们使用 libaio 进行异步 IO。

我有一个 linux 嵌入式环境。

这里我有2个场景：

A：

1. 打开并写入一个临时文件。
2. 将临时文件重命名为原始文件。
3. 电力流失

结果：重新启动后，我拥有的是：

• 0 大小的原始文件，并且没有临时文件。

乙：

1. 打开并写入一个临时文件。

2. FSYNC临时文件。

3. 将临时文件重命名为原始文件。

4. 电力流失

结果：重启后，

• 保留原始文件的原始内容，但未实现
• 0 大小的临时文件

如您所见，在这两种情况之间，唯一的区别是临时文件的 fsync，而不是原始文件。在这两种情况下，我都没有 fsync 原始文件。

那么，为什么原始文件的原始内容会保留在场景 B 中呢？

从原始文件的角度来看，更改是通过重命名non-fsynced file vs fsynced file来实现它。

这如何保留原始内容？

编辑：

这种实现原始文件的场景也未能安全地实现原始文件：

1. 打开并写入一个临时文件。

2. FSYNC 临时文件。

3. 将临时文件重命名为原始文件。

4. fsync 原始文件所在目录

5. 电力流失

结果：

0 大小的原始文件。

那么，我该怎么做呢？

我想安全地编写一个文件，但我不了解 fsync 的正确使用/位置。

https://linux.die.net/man/2/fsync

读完之后，我对在哪里有效地使用它感到困惑。

问题，我是否：

我正在写一些执行许多文件更改的东西。我看过编写原子的模块，但我想了解这个过程。