18.6. 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
Section 7.4.1, "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 -ns
Server 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
| | |
18.5. NFS async thread tuning | | 18.7. Mount point constructions |