Why would NFS have lag after a minute of inactivity

networkingnfsperformance

I am running a version 4 NFS server on a Salix server with kernel 3.10.17. I am mounting the NFS share with the command

sudo mount -t nfs 10.0.0.150:/share /mountpoint

on my client machine, which is the most recent version of Xubuntu (but I've had this problem with this NFS share across several different flavors and versions of Ubuntu clients over the past several years). The first time I access this mount point, such as through the file manager (just for an example, but any other kind of access has the same symptom), I have to wait 20 seconds before the data from the share loads. Once that happens, I can browse through the shared folders without any delay, at least until I let the mount go dormant (meaning I don't try to access anything under it) for about a minute, after which I would experience the delay again. My client is also NFS v4.

Here is the output of nfsstat -m on the client:
rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.214,local_lock=none,addr=10.0.0.150

I am sharing the same folder on the server through SAMBA for my Windows clients, and there are no issues with the SAMBA share.

Best Answer

I found the problem. For NFS v4 server, there is a file /proc/fs/nfsd/nfsv4revoverydir (at least for Slack-based Salix). The contents of this folder should be text which names another path. All of the solutions I found for this said to create the path found in that file, and it fixed the problem. In my case, this file was empty. Rather than trying to figure out how to get this /proc file populated properly, I used the work-around of configuring my server to use version 3 of NFS. I did this by editing the file /etc/rc.d/rc.nfsd and adding the option "-N 4" to the line which starts rpc.nfsd

Related Solutions

Mount Linux NFS – Fixing rpc.statd Not Running

statd is part of the package nfs-common. You could probably find that yourself with locate statd which gives you among others /etc/init.d/statd.

You can start statd with:

service statd start

But it should normally have started on system boot but maybe there is something else going wrong. You should check your log files: grep statd /var/log/* to see if there are reasons why that did not start.

Your /etc/exports looks ok to me. I use:

/data0    *(rw,no_root_squash,no_subtree_check)

on my server and:

192.168.0.2:/data0 /data0   nfs  defaults,noauto,user 0 0

in the /etc/fstab on my client.

Preventing broken NFS connection from freezing the client system

intr should allow for you to get control again when you hit ^C, but usually not immediately.

   intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the
                  file  operation  and cause it to return EINTR to the calling program.  The default is to not allow file
                  operations to be interrupted.

As you say, expectations are the problem here. Network problems can be temporary, but failing an operation is permanent. So most operations default to simply blocking until the operation completes.

This is the standard answer, but looking at a current man page I see this:

                  The  intr / nointr mount option is deprecated after ker-
                  nel 2.6.25.  Only SIGKILL can interrupt  a  pending  NFS
                  operation on these kernels, and if specified, this mount
                  option is ignored  to  provide  backwards  compatibility
                  with older kernels.

So it doesn't appear to me to be a NFS3/NFS4 issue, but a decision about how intr works. So you should be able to KILL the process, but that may not give you much utility.

I was unable to find the discussion about why the option was removed. Can you kill -KILL your process?

Best Answer

Related Solutions

Mount Linux NFS – Fixing rpc.statd Not Running

Preventing broken NFS connection from freezing the client system

Related Question