为什么Linux中的“nocto”NFS挂载选项不会阻止flush-on-close?

前端之家收集整理的这篇文章主要介绍了为什么Linux中的“nocto”NFS挂载选项不会阻止flush-on-close?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在学习NFS的近乎开放的政策,这会导致每个政策
文件关闭时刷新到服务器,以确保整体的一致性
客户端. (参见 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”应该以类似的速度提升来进行客户端缓冲,代价是其他客户端出现的数据滞后.

解决方法

nfs(5)手册页:

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.

原文链接:https://www.f2er.com/linux/396579.html

猜你在找的Linux相关文章