我遇到了与此类似的错误：
RHEL NFS 客户端在读取不断增长的文件时返回 NULL 字节
所以我的解决方案是检查 \0 字节并重新读取文件。这里的问题是，包含 \0 字节的错误文件缓存在运行 Java 应用程序的系统上。因此读取正确的文件内容需要相当长的时间。
当我这样做时，sync && echo 2 > /proc/sys/vm/drop_caches它会立即读取正确的内容。
我尝试添加syncNFS 挂载选项，但没有任何区别。
是否可以禁用特定挂载点的文件缓存？如果可以，该怎么做？
答案1
解决
该问题已在私人 Bug 702085 下与 Red Hat 工程部门进行了讨论，但无法在 RHEL 5 产品生命周期内修复。
Red Hat 产品管理部门选择不在 RHEL 6 中修复此问题，原因如下：
- 客户对此问题的关注度并不高。
- 此行为及其解决方法均记录在客户门户中。
- 与 RHEL 5 相比，在 RHEL 6 中重现这种行为更加困难（需要更长的时间）。
- NFS 协议不保证缓存一致性。
解决方法：
fcntl()通过使用文件锁（例如 shell 脚本或C 中的 flock），确保一个客户端在另一个客户端访问文件时无法读取该文件。- 使用 打开文件，
O_DIRECT以避免页面缓存。- 不要读过去末梢血。
- 例如，在 Python 中使用
os.stat()它来获取文件大小、os.open()打开文件并且os.read()仅读取文件大小范围内的内容。- 避免
tail -f在 NFS 挂载上的文件上运行。- 如果使用 RHEL 5，
syncmount 选项也能避免这个问题。但这在 RHEL6 中不起作用，因为该nfs_readpage_sync()功能在 RHEL 5 和 RHEL 6 之间被上游删除，因此该功能在 RHEL 6 中不存在。