我基本上有一个网站的网站服务器,另一个只存储文件.文件服务器通过挂载其中一个目录连接到主文件服务器.该网站运行Django所以我主要处理python.无论如何,我似乎遇到了一些问题,即文件被报告为不存在,即使它们实际存在.
基本上当我打电话时
filepath = '/path/to/file/on/nfs/share'
exists = os.path.exists(filepath)即使文件实际存在,exists仍然是假的,我知道它确实存在,因为我将时间戳打印到日志文件中,该日志文件准确显示它的创建时间.我不确定会出现什么问题,但我知道os.path.exists的文档说
On some platforms, this function may return False if permission is not granted to execute os.stat() on the requested file, even if the path physically exists.
我知道情况并非如此,因为这两个文件共享相同的组和组号,它们在两台服务器上共享相同的组号.它可能是一个陈旧的缓存或类似的东西？
我的安装是通过fstab自动完成的.
Client side, the settings are:
filehost:/filefolder /localfolder nfs defaults,rsize=32768,wsize=32768
Server side, the settings are:
/filefolder webserver(rw,sync,no_root_squash,no_subtree_check)编辑：
所以,我想更多的信息/细节.我正在运行一个Python子进程,在远程目录中生成一个文件.发出请求时,它会启动子进程并返回文件的预期位置.
在前端,有一个被ping的url,它调用该文件的os.path.exists(),然后当它执行时,资源通过ajax加载.
可疑的问题是,有时这个pinger会报告文件在实际存在后几秒钟内不可用.这也是我认为这可能是一个过时缓存问题的原因.
所有文件及其中的目录都是所有者/组www-data,以及由django实例化的任何子进程.此问题似乎也不完全可重复.有时它会很快工作,而其他人则会比预期的时间长几秒
解决方法:
这是由于找到了here的NFS缓存：
Attribute cache caches everything in struct stat, so stat() and fstat() calls can be returned from cache. If you need to see a file’s latest size or mtime (or other fields), you need to flush the file’s attribute cache before the stat() call.
Note that if file handle is cached, stat() returns information for that cached file (so the result is the same as for fstat()). If you need to stat() the latest file with the given file name, flush the file handle cache first.
我认为它的stat失败导致文件还没有在缓存中.
我在NFS手册页中找到了这个：
ac / noac – 选择客户端是否可以缓存文件属性.如果未指定任何选项(或者如果指定了ac),则客户端将缓存文件属性.
但是那里也有警告,所以我只是忍受延迟：
Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.
