Attribute caching
NFS clients cache file attributes such as the modification time and owner to avoid having to go to the NFS server for information that does not change frequently. The motivations for an attribute caching scheme are explained in "File attribute caching". Once a getattr for a filehandle has been completed, the information is cached for use by other requests. Cached data is updated in subsequent write operations; the cache is flushed when the lifetime of the data expires. Repeated attribute changes caused by write operations can be handled entirely on the client side, with the net result written back to the server in a single setattr. Note that explicit setattr operations, generated by a chmod command on the client, are not cached at all on the client. Only file size and modification time changes are cached. The lifetime of the cached data is determined by four mount parameters shown in Table 18-3.Table 18-3. Attribute cache parameters
| Parameter | Default (seconds) | Cache Limit |
|---|---|---|
| acregmin | 3 | Minimum lifetime for file attributes |
| acregmax | 60 | Maximum lifetime for file attributes |
| acdirmin | 30 | Minimum lifetime for directory attributes |
| acdirmax | 60 | Maximum lifetime for directory attributes |
The default values again vary by vendor, as does the accessibility of the attribute cache parameters. The minimum lifetimes set the time period for which a size/modification time update will be cached locally on the client. Attribute changes are written out at the end of the maximum period to avoid having the client and server views of the files drift too far apart. In addition, changing the file attributes on the server makes those changes visible to other clients referencing the same file (when their attribute caches time out).Attribute caching can be turned off with the noac mount option:
#mount -o noac mahimahi:/export/tools /mnt
Without caching enabled, every operation requiring access to the file attributes must make a call to the server. This won't disable read caching (in either NFS async threads or the VM system), but it adds to the cost of maintaining cache consistency. The NFS async threads and the VM system still perform regular cache consistency checks by requesting file attributes, but each consistency check now requires a getattr RPC on the NFS server. When many clients have attribute caching disabled, the server's getattr count skyrockets:
%nfsstat -nsServer nfs: calls badcalls 221628 769 Version 2: (774 calls) null getattr setattr root lookup readlink 8 1% 0 0% 0 0% 0 0% 762 98% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 0 0% 0 0% 4 0% Version 3: (219984 calls) null getattr setattr lookup access readlink 1173 0% 119692 54% 4283 1% 31493 14% 26622 12% 103 0% read write create mkdir symlink mknod 11606 5% 7618 3% 1892 0% 64 0% 37 0% 0 0% remove rmdir rename link readdir readdirplus 3183 1% 2 0% 458 0% 1295 0% 156 0% 1138 0% fsstat fsinfo pathconf commit 7076 3% 311 0% 78 0% 1704 0%
Upwards of 60% of the NFS calls handled by the server may be requests to return file or directory attributes. If changes made by one client need to be reflected on other clients with finer granularity, the attribute cache lifetime can be reduced to one second using the actimeo option, which sets both the regular file and directory minimum and maximum lifetimes to the same value:
#mount -o actimeo=1 mahimahi:/export/tools /mnt
This has the same effect as:
#mount -o acregmin=1,acregmax=1,acdirmin=1,acdirmax=1 \mahimahi:/export/tools /mnt