文件在关闭时刷新到服务器,以确保整体的一致性
客户端. (参见 http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch07_04.htm.)当尝试编写许多小文件时,这会导致性能大打折扣.
显然,我知道“异步”导出选项,但也有“nocto”
客户端挂载选项,它应该禁用close-to-open机制
对那个客户.据我所知,这应该会阻止客户端
从文件关闭时清除文件(以及不打扰检查
打开时缓存一致性).但是,这似乎没有效果:
客户端仍在关闭文件到服务器,导致大量
等待-10.
有没有人知道为什么“nocto”没有我希望它的效果
将? “async”选项按预期工作,但对我来说更重要
在这种情况下客户端缓存是正确的,它只是让我烦恼.
示例:一组无盘节点共享一个远程根,偶尔会从其中一个节点更新.每个文件在关闭后立即刷新并不重要,因为没有其他节点尝试写入同一文件.但是,更重要的是,如果服务器在更新一组软件包时崩溃,客户端会知道哪些数据尚未写入服务器的磁盘,因此一旦服务器再次运行,它就可以再次尝试.使用“async”选项,此方案可能会导致数据丢失(因为服务器将客户端关于刷新到磁盘的数据),而禁用close-to-open(并使用“sync”而不是“async”)应该从理论上讲,在没有潜在数据丢失的情况下提供相同的性能优势(因为几个文件写入将被缓冲并一起刷新到服务器).服务器和其他客户端会看到稍微过时的文件系统视图(几秒钟).这对我来说似乎很合理.
简单地说,“async”可以进行服务器端缓冲,从而大大提高了速度.我期待的是“nocto”应该以类似的速度提升来进行客户端缓冲,代价是其他客户端出现的数据滞后.
解决方法
If the
nocto
option is specified,the client uses a non-standard heuristic to determine when files on the server have changed.Using the
nocto
option may improve performance for read-only mounts,but should be used only if the data on the server changes only occasionally. The DATA AND MetaDATA COHERENCE section discusses the behavior of this option in more detail.