这是一个老问题了，超过21个月之后，重新拿出来记录一下。
问题出现在2009年，在2009年3月12-15日期间，专门针对此问题向网闸和操作系统的厂商提交了问题，经过多次邮件交涉(GMAIL有记录)，最终对问题有了基本认识。当时邮件不少，却没有汇总报告，今天刚好想起来就简单汇总一下。
此问题的现象是，在nfs server上能看到/ datacenter/collected/
文件送到server上用的是ftp协议，一个java程序在轮询flag目录，发现有新文件就处理掉。结果就是文件已经存在很久了，程序就是找不到该文件，用ls也看不到。
最开始怀疑问题出现在穿透网闸，再后来把测试程序写出来以后，在不走网闸的情况下，也会出现问题，只是频率不同而已，因此最终把火力瞄准了nfs，而不是网闸。
共享用的是nfs协议，开始以为是nfs server有问题，后来查找资料，发行是nfs client的caching问题。
To
free
to
/proc/sys/vm/drop_caches.
Because this is a non-destructive operation
are not freeable, the user should run
在问题出现时，用ls命令是看不到文件的，但是如果知道确切文件名的话，可以用stat命令显示该文件的信息，但是如果stat *仍然看不到，在nfs server上则所有问题都不存在，说明文件确确实实写到磁盘上了。
处理办法：
1，改用cifs共享方式。CIFS协议无此问题。我最终选用了这个方案。
2，定时touch一下flag目录，这个方法最简单，且普通用户就可以了。
3，定时清缓存。如果去清除cache，有可能会导致脏数据丢失，因此必须事先发出sync命令，且必须以root来执行。个人觉得这个方法不现实，频率掌握不了，且需要root权限，就没做详细测试。
经验值：测试程序非常重要，专门写的制造此问题的程序，可以在公司的实验环境中将问题复现出来，且频率提高以后，还可以将网闸等非关键要素给筛选过滤出局。
问题的终极解决办法，估计需要等nfs协议的v4版本NFS v4 (pNFS)来彻底解决，并且在v4本身已经采用了全新的协议方式，估计可以从根本上避免此问题。实际上，v4发展的是相当的慢。
