Chapter 10. Using the cache with NFS
NFS will not use the cache unless explicitly instructed. This paragraph shows how to configure an NFS mount by using FS-Cache.
The cachefilesd package is installed and running. To ensure it is running, use the following command:
# systemctl start cachefilesd # systemctl status cachefilesd
The status must be active (running).
Mount NFS shares with the following option:
# mount nfs-share:/ /mount/point -o fsc
All access to files under
/mount/pointwill go through the cache, unless the file is opened for direct I/O or writing. For more information, see Cache limitations with NFS.
NFS indexes cache contents using NFS file handle, not the file name, which means hard-linked files share the cache correctly.
NFS versions 3, 4.0, 4.1 and 4.2 support caching. However, each version uses different branches for caching.
10.1. Configuring NFS cache sharing
There are several potential issues to do with NFS cache sharing. Because the cache is persistent, blocks of data in the cache are indexed on a sequence of four keys:
- Level 1: Server details
- Level 2: Some mount options; security type; FSID; uniquifier
- Level 3: File Handle
- Level 4: Page number in file
To avoid coherency management problems between superblocks, all NFS superblocks that require to cache the data have unique Level 2 keys. Normally, two NFS mounts with same source volume and options share a superblock, and therefore share the caching, even if they mount different directories within that volume.
This is an example how to configure cache sharing with different options.
Mount NFS shares with the following commands:
mount home0:/disk0/fred /home/fred -o fsc mount home0:/disk0/jim /home/jim -o fsc
/home/jimlikely share the superblock as they have the same options, especially if they come from the same volume/partition on the NFS server (
To not share the superblock, use the
mountcommand with the following options:
mount home0:/disk0/fred /home/fred -o fsc,rsize=8192 mount home0:/disk0/jim /home/jim -o fsc,rsize=65536
In this case,
/home/jimwill not share the superblock as they have different network access parameters, which are part of the Level 2 key.
To cache the contents of the two subtrees (
/home/fred2) twice with not sharing the superblock, use the following command:
mount home0:/disk0/fred /home/fred1 -o fsc,rsize=8192 mount home0:/disk0/fred /home/fred2 -o fsc,rsize=65536
Another way to avoid superblock sharing is to suppress it explicitly with the
nosharecacheparameter. Using the same example:
mount home0:/disk0/fred /home/fred -o nosharecache,fsc mount home0:/disk0/jim /home/jim -o nosharecache,fsc
However, in this case only one of the superblocks is permitted to use cache since there is nothing to distinguish the Level 2 keys of
To specify the addressing to the superblock, add a unique identifier on at least one of the mounts, i.e.
mount home0:/disk0/fred /home/fred -o nosharecache,fsc mount home0:/disk0/jim /home/jim -o nosharecache,fsc=jim
Here, the unique identifier
jimis added to the Level 2 key used in the cache for
The user can not share caches between superblocks that have different communications or protocol parameters. For example, it is not possible to share between NFSv4.0 and NFSv3 or between NFSv4.1 and NFSv4.2 because they force different superblocks. Also setting parameters, such as the read size (rsize), prevents cache sharing because, again, it forces a different superblock.
10.2. Cache limitations with NFS
There are some cache limitations with NFS:
- Opening a file from a shared file system for direct I/O automatically bypasses the cache. This is because this type of access must be direct to the server.
- Opening a file from a shared file system for either direct I/O or writing flushes 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.