我碰到了一个类似于这个bug的bug：
RHEL NFS客户端在读取增长的文件时返回NULL字节
所以我的解决scheme是检查\ 0字节并重新读取文件。 这里的问题是，包含\ 0字节的错误文件被caching在运行java应用程序的系统上。 因此，阅读正确的文件内容需要相当长的一段时间。
当我做sync && echo 2 > /proc/sys/vm/drop_caches它立即读取正确的内容。
我试图添加sync到NFS挂载选项没有区别。
是否可以禁用特定挂载点的文件caching？ 如果是的话，该怎么做？
parsing度
这个问题在Red Hat工程公司的Private Bug 702085下讨论过，但在RHEL 5产品生命周期内无法修复。
由于以下原因，红帽产品pipe理部门select不在RHEL 6中修复此问题：
- 客户暴露于这个问题并不重要。
- 客户门户上logging了此行为以及变通办法。
- 与RHEL 5相比，这种行为在RHEL 6中难以复制（需要更长的时间）。
- NFS协议不保证caching一致性。
解决方法：
- 确保一个客户端在另一个客户端通过使用文件锁（如shell脚本中的flock
fcntl()或者c中的fcntl()访问文件时不能读取文件。- 用
O_DIRECT打开文件，避免页面caching。- 不要读过EOF 。
- 例如，在Python中使用
os.stat()来获取文件大小，os.open()打开文件，而os.read()只能读取文件大小。- 避免在NFS挂载的文件上运行
tail -f。- 如果使用RHEL 5，
sync安装选项也将避免此问题。 这在RHEL6中不起作用，因为在RHEL 5和RHEL 6之间上游移除了nfs_readpage_sync()函数，因此该函数在RHEL 6中不存在。