尽管使用了 fsync，但未调用 NFS COMMIT 操作

Question

我一直在进行一些详细的测试，以确定async模式下的NetApp NFS（v3 协议）服务器是否正确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工具。它使用多种方式来发布基准测试的同步和报告，以便您可以确定哪种方式最适合您的系统。

时间差异test_fsync表明 fsync 函数在async挂载上执行的时间比sync挂载要长，大概是因为在sync挂载中，数据一直在刷新，只有在fsync调用时才会刷新数据。但是，时间差异非常不稳定，我可能只是遇到了性能瞬态问题。

使用该sync选项安装服务器没有任何改变。

更新：情节变厚了。

在 Ubuntu/Mint 17、Linux 内核 3.13.0（nfs 版本：1.2.8）上，我设置了一个环回挂载点，带有同步和异步选项，然后重新运行测试。速度差异肯定表明同步和异步之间存在差异。nfsstat显示在每次运行之后pg_fsync_test，恰好发生了1 个COMMIT。

跆拳道

Answer 1

一位同事找到了一个可能的答案：

Netapp 技术报告 tr-3183（通过 NFS 将 Red Hat 客户端与 NetApp 存储结合使用）表示：

Data ONTAP 的 NFS 服务器会将所有写入请求提升为 FILE_SYNC，无论客户端请求 UNSTABLE、DATA_SYNC 还是 FILE_SYNC 写入。因此，客户端在写入 NetApp 存储时无需发送 COMMIT 请求，因为所有写入都记录在 NVRAM 中，并且客户端会立即获得写入确认。因此，NetApp 存储的写入本质上是异步的，而且速度要快得多。