我一直在学习NFS的接近开放策略，这会导致每个文件在closures时都被刷新到服务器上，以确保客户端的一致性。 （请参阅http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch07_04.htm 。）当尝试写入许多小文件时，会导致性能下降。
我知道显然是“asynchronous”导出选项，但也有一个“nocto”客户端安装选项，它应该禁用该客户端的close-to-open机制。 据我所知，这应该阻止客户端在closures时刷新文件（以及在打开时不检查caching一致性）。 但是，这似乎没有任何影响：客户端仍然将文件刷新到服务器上，导致大量的等待。
有没有人有任何想法，为什么“nocto”没有我希望会的影响？ “asynchronous”选项按预期工作，但对我来说更重要的是客户端caching在这种情况下是正确的，这只是让我感到困惑。
例如：一组无盘节点共享远程根，偶尔从其中一个节点更新。 每个文件在closures后立即刷新并不重要，因为没有其他节点正在尝试写入同一个文件。 但更重要的是，如果服务器在更新一组软件包时崩溃，则客户端知道哪些数据还没有写入服务器的磁盘，以便一旦服务器重新启动就可以再次尝试。 使用“asynchronous”选项，这种情况下可能会导致数据丢失（因为服务器对客户端的数据被刷新到磁盘），而禁用closures打开（并使用“同步”，而不是“asynchronous”）在理论上提供相同的性能优势，而不会造成潜在的数据丢失（因为多个文件写入将被缓冲并一起刷到服务器）。 服务器和其他客户端会看到文件系统的一个稍微过时的视图（几秒钟）。 这对我来说似乎是合理的。
简单地说，“asynchronous”就是服务器端的缓冲，这会加快速度。 我期望的是“nocto”应该做客户端缓冲，类似的速度提升，代价是在其他客户端出现一些数据滞后。
从nfs（5）手册页：
如果指定了
nocto选项，则客户端使用非标准启发式来确定服务器上的文件何时发生更改。使用
nocto选项可以提高只读安装的性能，但只有在服务器上的数据偶尔更改时才能使用。 数据和元数据一致性部分将更详细地讨论此选项的行为。