2009年3月发现的一个nfs caching问题

这是一个老问题了，超过21个月之后，重新拿出来记录一下。

问题出现在2009年，在2009年3月12-15日期间，专门针对此问题向网闸和操作系统的厂商提交了问题，经过多次邮件交涉(GMAIL有记录)，最终对问题有了基本认识。当时邮件不少，却没有汇总报告，今天刚好想起来就简单汇总一下。

此问题的现象是，在nfs server上能看到/ datacenter/collected/test/flag下面有文件，但是在nfs client上看不到。

文件送到server上用的是ftp协议，一个java程序在轮询flag目录，发现有新文件就处理掉。结果就是文件已经存在很久了，程序就是找不到该文件，用ls也看不到。

最开始怀疑问题出现在穿透网闸，再后来把测试程序写出来以后，在不走网闸的情况下，也会出现问题，只是频率不同而已，因此最终把火力瞄准了nfs，而不是网闸。

共享用的是nfs协议，开始以为是nfs server有问题，后来查找资料，发行是nfs client的caching问题。

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to


free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;


to free pagecache, dentries and inodes, use echo 3 >


/proc/sys/vm/drop_caches.




Because this is a non-destructive operation and dirty objects


are not freeable, the user should run sync(8) first.

在问题出现时，用ls命令是看不到文件的，但是如果知道确切文件名的话，可以用stat命令显示该文件的信息，但是如果stat *仍然看不到，在nfs server上则所有问题都不存在，说明文件确确实实写到磁盘上了。

处理办法：

1，改用cifs共享方式。CIFS协议无此问题。我最终选用了这个方案。

2，定时touch一下flag目录，这个方法最简单，且普通用户就可以了。

3，定时清缓存。如果去清除cache，有可能会导致脏数据丢失，因此必须事先发出sync命令，且必须以root来执行。个人觉得这个方法不现实，频率掌握不了，且需要root权限，就没做详细测试。

经验值：测试程序非常重要，专门写的制造此问题的程序，可以在公司的实验环境中将问题复现出来，且频率提高以后，还可以将网闸等非关键要素给筛选过滤出局。

问题的终极解决办法，估计需要等nfs协议的v4版本NFS v4 (pNFS)来彻底解决，并且在v4本身已经采用了全新的协议方式，估计可以从根本上避免此问题。实际上，v4发展的是相当的慢。