CacheFS

A fundamental factor in computer performance is file access time. In a networked environment using NFS, every file access request across the network affects performance. The Cache File System (CacheFS) can be used to improve performance of NFS-mounted file systems or slow devices such as a CD-ROM. When a file system is cached, the data read from the remote file system or CD-ROM is stored in a cache on the local system’s disk. First, let’s introduce some terms:

• Back file system The file system on the remote host, or CD-ROM, that is being cached. Typically, this is an NFS or HSFS file system. Files in the back file system are called back files.

• Front file system The file system that contains the cached data, typically a UFS file system. Files in the front file system are called front files.

• Cached file system The file system that resides on the local disk. Files in it are cached files.

• Cache directory The directory on the local disk where the data for the cached file system is stored.

• Cold cache A cache that does not yet have any data in its front file system. To create a cache, requested data must be copied from the back file system to the front file system. This is referred to as populating the cache. An attempt to reference data that is not yet cached is referred to as a cache miss.

• Warm cache A cache that contains the desired data in its front file system. Requested data is available to the user without requiring any action from the back file system. An attempt to reference data that is already cached is referred to as a cache hit.

Creating the Cache

A cache must exist before a CacheFS mount can be performed. No special disk partitioning is required for cache creation. A cache file system can be created in a subdirectory of an existing file system, or you can dedicate an entire file system to caching. The only requirement is that you create the cache in mounted local file systems. The cfsadmin command creates the local cache.

Two steps are involved in setting up a cached file system:

cfsadmin -c <cache-directory> 

mkdir /local 
cfsadmin -c  /local/cache1 

mount -F cachefs -o backfstype=<fstype>,cachedir=<cache-directory>,  
[options] <back-filesystem mount-point> 

The following example creates the mount point /sparc21data and mounts the NFS file system sparc21:/data as a cached file system named /sparc21data in the cache named /local/cache1:

mkdir /sparc21data 
mount -F cachefs -o backfstype=nfs,cachedir=/local/cache1 sparc21:/data /sparc21data 

Now the CacheFS mount point, /sparc21data, can be accessed just like any other mounted file system.

To make the mount point permanent, add the following line to your /etc/vfstab file, as follows:

sparc21:/data  /local/cache1  /sparc21data  cachefs  3  yes   
backfstype=nfs,cachedir=/local/cache1 

Verify that the cache you created was actually mounted by using the cachefsstat command, as follows:

cachefsstat /sparc21data 
      /sparc21data 
      cache hit rate:    0%    (0 hits, 8 misses) 
      consistency checks:     7     (5 pass, 2 fail) 
      modifies:     0 
      garbage collection:     0 

If the file system was not mounted in the cache, you will receive an error message similar to the following:

cachefsstat /sparc21data 
cachefsstat: /sparc21data: not a cachefs mountpoint 

Some overhead is involved when data is initially referenced from the CacheFS file system associated with the cache population, but subsequent references to the same data can be satisfied without access to the back file system. A warm cache provides performance close to that of a local file system, without the administration and overhead associated with local file systems. The performance of the CacheFS file system over traditional NFS mounts is much faster for clients accessing slow network links or heavily loaded servers.

You can also cache more than one file system in the same cache. There is no need to create a separate cache for each CacheFS mount. In other words, you should need to run cfsadmin -c only once to create a single cache for all your CacheFS mounts.

Many types of back file systems can potentially be cached. For example, there are performance benefits to caching slow media such as a CD-ROM on a faster hard drive using CacheFS. However, local file systems are usually not cached.

Any file system that is “read mostly” is a likely candidate for caching. An example of an excellent candidate for caching is /usr/share/man. File systems that are usually read one time only, such as /var/mail, are not good candidates for caching because data is typically read once and then discarded. In this case, you pay the cost of cache population without gaining the benefits of subsequent cache accesses.

CacheFS provides no benefit for write operations. This is because CacheFS is strictly a “write-through” cache. CacheFS write performance will never be any better than that of the back file system.

CacheFS is not an NFS performance accelerator. It’s possible that a single client will not see much of a performance boost from caching, particularly on a lightly loaded fast LAN on which the server is a powerful machine with fast disks without much load. The benefits of caching show up on busy networks with heavily loaded servers.

Monitoring the Cache

You can use CacheFS statistics to monitor the performance of your cache to determine the appropriate cache size. The three commands listed in Table 22.5 help you determine the trade-off between your cache size and the desired performance of the cache.

The default values for the cache parameters used by cfsadmin are for a cache to use the entire front file system for caching. The parameter values should be changed if the cache is limited to only a portion of the front file system. The cfsadmin command enables you to specify the options listed in Table 22.6.

You should not need to change any of these parameter values. They are set to default values to achieve optimal cache behavior. However, as shown in the next example, you might want to modify the maxblocks and maxfiles settings if you have some room in the front file system that is not used by the cache and you want to use it for some other file system. The following example creates a cache named /local/cache1 that can use up to 80 percent of the disk blocks in the front file system. It can grow to use 55 percent of the front file system blocks without restriction unless 60 percent (or more) of the front file system blocks is already used:

cfsadmin -c -o maxblocks=80,minblocks=55,threshblocks=60 /local/cache1 

To modify a CacheFS parameter, first unmount the file system. The following example unmounts /local/cache1 and changes the threshfiles parameter to 65 percent:

umount /sparc21data 
cfsadmin -u -o threshfiles=65 /local/cache1 
mount /sparc21data 

To display information about all file systems cached under the specified cache directory, type this line:

cfsadmin -l <directory_name> 

Then press Enter.

The following example illustrates how to display cache information:

cfsadmin -l /local/cache1 

The system responds with this:

cfsadmin: list cache FS information 
    maxblocks     90% 
    minblocks     0% 
    threshblocks  85% 
    maxfiles      90% 
    minfiles      0% 
    threshfiles   85% 
    maxfilesize   3MB 
  sparc21:_data:_mnt 
  sparc21:_data:_sparc21data 

The output displays statistics followed by the cacheID of all file systems stored in the cache. For example, the cacheID for the sparc21data file system is as follows:

Sparc21: data: sparc21data 

Deleting a Cache

Before you delete a cached file system, you must unmount all the cached file systems for that cache directory.

To delete a file system in a cache, type this:

cfsadmin -d <cache_id> <cache_directory> 

Then press Enter.

<cache_id> is part of the information returned by cfsadmin -l . In the previous example of the cfsadmin –l command, the cacheID was displayed as the last line of the output and is sparc21: data: sparc21data.

After one or more file systems are deleted, you must run the fsck -F_cachefs command to correct resource counts for the cache. The next example unmounts a cached file system, deletes it from the cache, and runs fsck_-F cachefs:

umount /sparc21data 
cfsadmin -d sparc21:_data:_sparc21data  /local/cache1 
fsck -F cachefs /local/cache1 

You can delete all file systems in a particular cache by using all as an argument to the -d option, as shown in the following example. This example deletes all file systems cached under /local/cache1 and the specified cache directory:

cfsadmin -d all /local/cache1

Checking Consistency

To ensure that the cached directories and files are kept up-to-date, CacheFS periodically checks the consistency of files stored in the cache with files on the back file system. To check consistency, CacheFS compares the current modification time to the previous modification time. If the modification times are different, all data and attributes for the directory or file are purged from the cache, and new data and attributes are retrieved from the back file system.

When a user requests an operation on a directory or file, CacheFS checks to see if it is time to verify consistency. If it is, CacheFS obtains the modification time from the back file system and performs the comparison.

By default, CacheFS does always perform cache consistency checking. When the noconst keyword is specified with the mount command, consistency checking is disabled. In this mode, no attempt is made to see that the cache remains consistent with the back file system. In the case of a read-only back file system, consistency checking is completely unnecessary. Use the noconst keyword when the back file system is a read-only file system.

By specifying the demandconst option of the mount command, you can perform consistency checks only when you explicitly request them for file systems mounted with this option. After specifying the demandconst option when you mount a file system in a cache, you use the cfsadmin command with the -s option to request a consistency check. By default, consistency checking is performed file by file as files are accessed. If no files are accessed, no checks are performed. Use of the demandconst option avoids a situation in which the network is flooded with consistency checks.

The following example uses the demandconst option to specify consistency checking on demand for the NFS cached file system /sparc21data, whose back file system is sparc21:/data:

mount -F cachefs -o backfstype=nfs,cachedir=/local/cache1,demandconst  
sparc21:/data /sparc21data