Skip to main content
Skip table of contents

Known Good NFS Cache Mount Options

Introduction to NFS Cache experiences

We've experienced cases where the external mounted file server had file system issues. It leads to a hanging mount (a 'df -kh' did not complete its output/get no prompt). This leads to the fact that censhare wasn't logging in server-0.0.log as the java process didn't get CPU time. Users can't login or work. The NFS Cache mount parameters avoided this situations.

The only problem logged in users face was that the checkout/it was slow which can be easily correlated to a storage problem. It is recommended to to set the known good NFS Cache mount options in order to avoid that stale NFS handle errors have an impact to a censhare System and are experienced as a performance issue. There are multiple ways to achieve, but usually it is done by adding the actimeo=3,timeo=100 options to mount.

NFS Cache Mount Example

CODE
server:/export       /usr       nfs       bg,soft,nolock,vers=3,actimeo=3,timeo=100

Troubleshooting

Symtoms Error in Log entries: If you find one of the following typical log entries then you need to set the known good NFS cache mount parameters which are shown in the example.

CODE
# less  /var/log/messages
Sep 8 18:13:39 server nfs: [ID 733954 kern.info] NOTICE: [NFS4][Server: server][Mntpt: /opt/censhare]NFS server hostname not responding; still trying

...
Mar 23 09:38:15 server systemd: nfs.mount mounting timed out.

When you face issue like slowness or 'df -kh' doesn't respond, in that case you can use the options given in the example.

CODE
hostname:/export-dir  /mount-point  nfs  bg,soft,nolock,vers=3,actimeo=3,timeo=100


General

To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server’s version of each file’s attributes for updates. Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server. Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. Therefore we recommend the following alternate options which also disables attribute caching: actimeo, timeo.

actimeo=n

Using actimeo sets all of acregmin, acregmax, acdirmin, and acdirmax to the same value. If this option is not specified, the NFS client uses the defaults for each of these options listed above.

acregmin=n The minimum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 3-second minimum.

acregmax=n The maximum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 60-second maximum.

acdirmin=n The minimum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 30-second minimum.

acdirmax=n The maximum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 60-second maximum.

When setting the actimeo=0 all attribute caches will time out in 0 seconds, technically achieving what noac does, to not use caching. It is reasonable to expect it would inflict the same performance penalty, but testing shows that impact is much less.

timeo=n

The time in deciseconds (tenths of a second) the NFS client waits for a response before it retries an NFS request. For NFS over TCP the default timeo value is 600 (60 seconds). The NFS client performs linear backoff: After each retransmission the timeout is increased by timeo up to the maximum of 600 seconds. However, for NFS over UDP, the client uses an adaptive algorithm to estimate an appropriate timeout value for frequently used request types (such as READ and WRITE requests), but uses the timeo setting for infrequently used request types (such as FSINFO requests). If the timeo option is not specified, infrequently used request types are retried after 1.1 seconds. After each retransmission, the NFS client doubles the timeout length of 60 seconds



JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.