我一直在进行一些详细的测试，以确定我们的 NetApp NFS（v3 协议）服务器在async模式下是否正确地满足客户端的fsync请求。当我发现 Linux（RHEL 6，内核 2.6.32-431.5.1）根本不会发出 COMMIT 操作时，我遇到了麻烦！通过使用该nfsstat工具和通过nfstrace 工具。没有一个 COMMIT。
这似乎违反了NFS 语义:
当在 close(2) 或 fsync(2) 系统调用期间将安全异步写入刷新到服务器时，或者遇到内存压力时，版本 3 客户端使用 COMMIT 操作。
到底是怎么回事？
笔记：
挂载点肯定是通过异步操作挂载的（这是默认的）。
为了生成 fsync 请求，我使用了 Postgresql 的test_fsync工具。它使用多种方式来发布基准同步和报告，以便您可以确定哪种方式最适合您的系统。
时间差异表明 fsync 函数在挂载上执行的时间比在挂载test_fsync上执行的时间长，大概是因为在挂载时，数据一直在刷新，并且只有在调用时才会刷新数据。然而，时间差异非常不稳定，我可能只是遇到性能瞬态。asyncsyncsyncfsync
使用该选项安装服务器sync没有任何改变。
更新：情节变得更加复杂。
在 Ubuntu/Mint 17、Linux 内核 3.13.0（nfs 版本：1.2.8）上，我设置了一个环回挂载点，同时具有同步和异步选项，并重新运行测试。速度差异肯定表明同步和异步之间存在差异。nfsstat表明每次运行后pg_fsync_test，准确地1COMMIT 发生了。
搞什么鬼
答案1
一位同事找到了一个可能的答案：
Netapp 技术报告 tr-3183（通过 NFS 将 Red Hat 客户端与 NetApp 存储结合使用）表示：
Data ONTAP 的 NFS 服务器会将所有写入请求提升为 FILE_SYNC，无论客户端请求 UNSTABLE、DATA_SYNC 还是 FILE_SYNC 写入。因此，客户端在写入 NetApp 存储时无需发送 COMMIT 请求，因为所有写入都记录在 NVRAM 中，并且客户端会立即获得写入确认。因此，NetApp 存储的写入本质上是异步的，而且速度要快得多。