NFScaching适合caching大文件（200kb到50mb？）

NFS方式：

如果客户端服务器上的空间不足以防止您保留所有大型文件的完整副本（例如，您只需要或需要caching最常访问的文件），FS-Cache可能会有所帮助。

有一些注意事项（从Red Hat的文档中可以看出 ）：

• 从共享文件系统中打开直接I / O文件将自动绕过caching。 这是因为这种访问types必须直接连接到服务器。
• 从共享文件系统中打开文件以进行写入在NFS版本2和3上将不起作用。这些版本的协议不能为客户端提供足够的一致性pipe理信息，以检测来自另一个客户端的同一文件的并发写入。
• 因此，从共享文件系统中为直接I / O或写入打开文件将刷新文件的caching副本。 FS-Cache将不会再次caching文件，直到不再为直接I / O或写入而打开。
• 而且，这个FS-Cache的版本只caching常规的NFS文件。 FS-Cache不会caching目录，符号链接，设备文件，FIFO和套接字。

此外，您需要在NFS客户端上运行特定types的文件系统，以便为FS-Cache用于跟踪事件的文件系统属性提供所需的FS支持（使用user_xattr，ext4，btrfs，xfs的ext3） 。

rsync的方式：

另一种select是使用rsync并保留每个系统上的文件的完整副本。 如果这些只是周期性的变化（例如每天或每周），那么从pipe理和debugging问题的复杂性较低的angular度来看，这可能对您更有利。

这样做的缺点是你现在保留N + 1个副本，其中N是你需要运行这个系统的系统的数量，你将不得不想出一个定期处理rsyncs的机制（例如，脚本+ cron等等）。

我看到你用squid标记了你的问题，所以你清楚地知道它。 你怎么用它？ 我认为你的问题可以通过在反向代理（httpd-accelerator）模式下使用squid来解决。 如果你的设置正确，那么你不应该担心NFS方面。