我观看了演讲：“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 获取这些故障？