[SOLVED] Arch client nfs mounts are slow and transient

mostlyharmless · 02-14-2016, 10:37 AM

So, I have a nfs server running good old Slackware 13.x, Linux 3.10.17-kirkwood. The client is Arch. The problem is that although Arch mounts the directory, the actual files aren't actually available via any file manager, or program (eg LibreOffice) until several seconds go by.. Nemo, for example, will be blank and say Loading....

Once it's been "loaded", access is fine, but of course if I don't access the directory mount for awhile, the problem apparently recurs. Arch must, at some point, be "unloading" the mount point (although the filesystem is still mounted according to mount).

I have used this same server for Slackware on the same client hardware, without any such delays. I also haven't had any problems from Windows machines on the local network (mounting nfs not smb) nor from RPi running debian/Raspbian. So it is Arch specific.

How can I stop this rather irritating behaviour? I'd just want the d*mn thing mounted and available, at all times, without a 10 second delay if I haven't looked at it recently.

Some information:

On the client:
nfsstat -c

Code:

Client rpc stats:
calls      retrans    authrefrsh
9242       0          9242    

Client nfs v4:
null         read         write        commit       open         open_conf    
0         0% 2600     28% 6         0% 0         0% 416       4% 3         0% 
open_noat    open_dgrd    close        setattr      fsinfo       renew        
0         0% 0         0% 334       3% 16        0% 3         0% 142       1% 
setclntid    confirm      lock         lockt        locku        access       
2         0% 2         0% 1         0% 0         0% 1         0% 807       8% 
getattr      lookup       lookup_root  remove       rename       link         
3987     43% 28        0% 1         0% 4         0% 10        0% 0         0% 
symlink      create       pathconf     statfs       readlink     readdir      
0         0% 1         0% 2         0% 21        0% 0         0% 514       5% 
server_caps  delegreturn  getacl       setacl       fs_locations rel_lkowner  
5         0% 329       3% 0         0% 0         0% 0         0% 1         0% 
secinfo      exchange_id  create_ses   destroy_ses  sequence     get_lease_t  
0         0% 0         0% 2         0% 0         0% 0         0% 0         0% 
reclaim_comp layoutget    getdevinfo   layoutcommit layoutreturn getdevlist   
0         0% 0         0% 0         0% 0         0% 0         0% 0         0% 
(null)       
0         0%

Running journalctl -f on the client usually says

Code:

nfs: server 192.168.1.100 not responding, still trying
Feb 14 09:09:35 bozo kernel: nfs: server 192.168.1.100 OK

occasionally, but not always says

Code:

Feb 14 09:11:27 bozo kernel: NFS: nfs4_handle_delegation_recall_error: unhandled

the filesystem is always mounted:

Code:

$mount
192.168.1.100:/data on /mnt/data type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=14,retrans=2,sec=sys,clientaddr=192.168.1.9,local_lock=none,addr=192.168.1.100,_netdev,user)

and the relevant /etc/fstab reads

Code:

192.168.1.100:/data /mnt/data nfs bg,_netdev,user,rsize=8192,wsize=8192,timeo=14,intr,nolock

#192.168.1.100:/data /mnt/data nfs auto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=20min,nolock 0 0

The second entry was an attempt on my part to resolve the situation: it did nothing to change the situation.

mdooligan · 02-15-2016, 05:09 AM

The async option in /etc/fstab and the client machine might help. It allows NFS requests to go through before they've been fully confirmed. If your network is reliable, you probably don't need sync.

Other thing that comes to mind is maybe the HD is powering down and you need to stop that. Some USB drives are particular culprits. I had a laptop that would not stop powering down it's drive with 5 minutes of inactivity. hdparm and other tools did not help. It was highly annoying. I made a cron script that did small writes to a stamp file on the drive every 4 minutes to keep it awake. It worked fine for years.

mostlyharmless · 02-15-2016, 09:31 AM

Thanks for the effort, but no joy. I tried the async option and it made no difference. I still get an interminable delay with

Code:

nfs: server 192.168.1.100 not responding, still trying
nfs: server 192.168.1.100 OK

Neither the server nor client's drives are idling and the server is rapidly responsive to other machines, even a Windows VM on the same Arch setup gets a faster response than the host, in fact it's near instantaneous.

mostlyharmless · 04-07-2016, 04:25 PM

In case anyone has the same problem, here's a work around, though not really a solution or answer: I mounted the file share as an smb mount with cifs instead of nfs. There are no more delays.

Rickkkk · 12-22-2016, 01:33 PM

Quote:

Originally Posted by mostlyharmless

In case anyone has the same problem, here's a work around, though not really a solution or answer: I mounted the file share as an smb mount with cifs instead of nfs. There are no more delays.

... in case you ever want to try nfs sharing again, I suggest making sure your hosts file contains an entry for your Slackware server. Also, I use the following options in my fstab file for nfs shares:

noauto,users,rsize=8192,wsize=8192,timeo=14,_netdev

... works well for me. The "noauto" I only use on laptops that aren't always connected to the network - your particular situation may not warrant the use of this option.

Cheers,