问题标签 [fsync]

我提交这个问题有两个原因：我在使用DBreeze在 下运行的数据库引擎时遇到了困难Mono，但我找到了一种解决方法，它可以帮助其他人解决这个确切的问题（我将解决方法作为答案发布），如果有人否则知道更好的解决方案，我将感谢您的帮助。

问题是DBreeze在 Windows 上正常工作，但在带有 Mono 的 Linux 上，在引擎初始化之后，第一次插入它会引发以下异常：

问题出在DBreeze/Storage/FSR.cs文件中，因为它试图调用

但这在 Mono 中不受支持。

问题是：如何正确刷新文件缓冲区/调用与 kernel32.dll 等效的文件FlushFileBuffers()以将缓冲区内容写入 Mono 下的磁盘？

我将 UBIFS 用于 NAND 上的 rootfs。当我使用 nano 命令编辑 /etc/rc.local 之类的文件并保存时，“cat /etc/rc.local”当然会显示编辑后的内容。但是在移除电源（没有reboot 或poweroff 命令）并再次供电后，/etc/rc.local 的内容变为空。

我发现写入的数据在UBIFS中并没有立即写入NAND并写入缓存。（参考：http ://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file ）

我想在编辑后直接同步到 NAND。我找到的唯一解决方案是 fsync，但这应该在 C 程序中调用，并且需要文件描述符。Nano 命令等没有给我们文件描述符。所以我无法解决这个同步问题。

如何解决这个不同步到 NAND 的问题？有同步命令吗？如果我想在 UBIFS 中编辑和保存文件，是否必须使用 C 程序编辑文件并使用 fsync？

我有一个 Jenkins 工作，将 git 代码签出到映射的网络文件共享，以便多个执行程序可以并行处理和测试代码。我估计在 90% 的时间里，一切都很好并且有效，然后似乎不知从何而来，我会遇到以下情况。

我不知道是什么突然导致这个或它来自哪里。这里指出：

正确的解决方案是不要将 Git 存储库存储在网络驱动器上。（我并不是要刻薄。这显然不是受支持的场景。）

但这是真的吗？有没有办法解决这个问题？除了偶尔的打嗝之外，这似乎工作得相当好，但我希望生成一个更具确定性的构建系统，它能够并行运行代码测试任务，而不必经常检查或移动我们的整个存储库。有谁知道我的问题可能是什么，或者他们是否找到了更一致的方法？

我在linux下有一些c应用程序。我正在重命名一些文件，rename(...) 如何确保将重命名持久写入底层磁盘？

使用文件，我可以执行以下操作：

我如何fsync（或类似）rename()在 c 中的 a 之后的目录？

通过iostat我可以发现每分钟一次磁盘写入的峰值。我认为这些峰值是由fsyncMongoDB 造成的，因为默认情况下，MongoDB 每 60 秒刷新一次数据到磁盘。我还可以发现慢查询日志中出现了与峰值一致的慢查询。

有一个名为storage.syncPeriodSecs的选项，但根据文档：

不要在生产系统上设置此值。在几乎所有情况下，您都应该使用默认设置。

更频繁地执行 fsync 可以减少峰值，所以我想知道在生产中更改这个值的风险。

我会很感激任何想法。

细节：

• MongoDB 版本：3.2.16

• 存储引擎：WiredTiger

• 高峰期间的缓慢查询：其中几个，大约 1 秒。不停止服务器

• 部署：分片集群。具有两个成员（主要 + 次要）的副本集

• 规格：CPU 8核，内存64GB，SSD盘

我正在编写一些使用fsync()系统调用来确保文件持久保存到磁盘的软件。我以前做过，而且我知道您需要注意的各种“陷阱”（即，在替换文件时，您需要fsync()对该文件，发出 a rename()，然后fsync()是包含目录。对软件进行持久编码将文件写入磁盘很好。

测试软件是另一回事。我想验证它在遇到停电等情况时是否正常运行。我的身体反应还不错，但还不足以拔掉两条 CPU 指令之间的电源线。

我应该如何测试写入磁盘的 C 程序的持久性？

（正如标题所暗示的那样，我假设您使用某种类似调试器的软件，可能使用ptrace(), 来在特定文件/行处自动终止您的程序，如可执行文件的调试信息中所列。）

我通过 C API 使用 RocksDB。

我有一个测试程序，它打开一个数据库，执行 1,000 次写入（在开始写入和回调之间收集时间数据），执行 1,000 次读取，然后关闭。

这行得通。写入的平均时间约为 1 毫秒。

我修改了测试程序以通过这个打开写同步

并再次运行它。写入的平均时间约为 8 毫秒。

到目前为止，一切都很好。

但是，我随后在程序的两个版本上运行 strace 以验证是否调用了 fsync() 或 fdatasync() 或 msync()。

no-sync 程序显示 4 次 fsync() 调用，2 次 fdatasync() 和 0 次 msync()。合理的。

...但程序的同步版本显示相同的 4、2 和 0。奇怪！奇怪！令人担忧！

同步版本确实显示了与非同步版本相比的 2 个有趣的增量：(i) 每次写入对 nanosleep() 的 2 次调用，(ii) 在 mmap() 中花费的时间增加了 80%。

一个出乎我意料的理论是，也许 msync() [或它的替代品]实际上是根据 nanosleep() 实现的？

这是在桌面 Linux 16.04 上

无论如何，我的问题是，根据主题行：

我是否正确地强制 RocksDB 使用 fsync？...因为 fsync() 和 msync() 都没有显示在 strace

谢谢。

这是原子文件更新的典型且众所周知的方法：

一般来说，如果我们还想要持久性（即保证新版本的文件在崩溃时可用），那么我们还需要调用fsync父目录。

问：UBIFS 也需要这个吗？文档说：

可以为目录调用 fsync() - 它同步目录 inode 元数据。[...]

对目录的 fdatasync() 调用在 UBIFS 中是“无操作”，并且所有更改目录条目的 UBIFS 操作都是同步的。

如果我没看错，后者（“所有更改目录条目的 UBIFS 操作都是同步的”）似乎暗示fsync不需要调用父目录。然而，我的测试似乎表明并非如此。我是误读了文档，还是这些信息过时了？

我观看了演讲：“PostgreSQL vs. fsync。PostgreSQL 怎么可能错误地使用 fsync 20 年，我们将如何处理它。” 通过https://fosdem.org/2019/schedule/event/postgresql_fsync/并阅读https://lwn.net/Articles/752063/作为背景。

如果你调用 fsync() 并且它失败了，那么真正简短和简化的总结是使用 Linux，不要认为你可以再次调用 fsync() 来修复它，因为第二次调用将成功并且你将在磁盘上损坏数据（第一次失败的调用后，失败的缓冲区缓存页面被标记为干净）。关于为什么会发生这种情况有很多细节（支持拔出 USB 的情况 - 您不想重试并保留永​​远不会成功的脏缓冲区缓存页面）。

FlushFileBuffers() 在这种情况下如何表现？我对通过 CIFS 访问的文件特别感兴趣，其中失败的可能性更大。

此外，鉴于操作系统可以在后台随时尝试将脏缓冲区缓存页面写入稳定存储，用户级程序如何通过 Win32 API 获取这些故障？

我正在尝试跟踪 Linux 中特定进程写入磁盘或从磁盘读取的总数据。使用 dstat 工具，我可以使用dstat -d. 使用strace -e trace=read,write，我可以跟踪系统调用的返回值。

这是一个示例程序，我想为其获取真实的系统读写值（包括写入磁盘和从磁盘读取的元数据）：

像这样的工具iotop也没有用，因为它们会给出不断变化的值。该dstat -d选项是我最接近跟踪实际读取、写入值的选项，但我只想将其缩小到一个特定的进程，而 dstat 没有这样的选项。

谢谢您的帮助！