The NFS way:
FS-Cache would likely help if you have minimal space on the client servers that prevents you from keeping full copies of all your large files (eg, you only want or need to cache the most frequently accessed files).
There are some caveats (as noted from Red Hat's documentation):
- Opening a file from a shared file system for direct I/O will automatically bypass the cache. This is because this type of access must be direct to the server.
- Opening a file from a shared file system for writing will not work on NFS version 2 and 3. The protocols of these versions do not provide sufficient coherency management information for the client to detect a concurrent write to the same file from another client.
- As such, opening a file from a shared file system for either direct I/O or writing will flush the cached copy of the file. FS-Cache will not cache the file again until it is no longer opened for direct I/O or writing.
- Furthermore, this release of FS-Cache only caches regular NFS files. FS-Cache will not cache directories, symlinks, device files, FIFOs and sockets.
Also, you're required to run on specific types of filesystems on the NFS client in order to provide the needed FS support for the filesystem attributes that FS-Cache uses to keep track of things (ext3 with user_xattr, ext4, btrfs, xfs).
The rsync way:
Another alternative is to use rsync and keep a full copy of the files on each system. If these are things that only change periodically (such as daily or weekly), this may be more beneficial to you from the stand point of having less complexity in managing and debugging of problems.
The downside to this is that you're now keeping N + 1 copies where N is the number of systems you need to run this on and you'll have to come up with a mechanism to handle the rsyncs periodically (eg, scripts + cron, etc).