nfs lock failure/hang when using alias address for server from linux

John jwd at SlowBlink.Com
Sun Aug 21 04:13:09 UTC 2011


   I have an nfs server running 9-current. Everything works as far
as nfs i/o operations are concerned.

   From another FreeBSD box, nfs locking works great to the server
when addressed by both it's real ip address and it's aliased ip

   From a Linux system:

Linux 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

   nfs locking works fine if the mount goes to the real ip address
of the server. If, however, the server is mounted by using it's aliased
ip address, while nfs i/o operations work fine, file locking hangs.

   On the server, the processes:

root   5995   0.0  0.0  14272   1920  ??  Ss    3:48PM    0:05.33 /usr/sbin/rpcbind -h -h -h -h
root   6021   0.0  0.0  12316   2364  ??  Ss    3:48PM    0:00.65 /usr/sbin/mountd -r -l -h -h -h -h
root   6048   0.0  0.0  10060   1864  ??  Ss    3:48PM    0:00.10 nfsd: master (nfsd)
root   6049   0.0  0.0  10060   1368  ??  S     3:48PM    0:00.20 nfsd: server (nfsd)
root   6074   0.0  0.0 274432   2084  ??  Is    3:48PM    0:00.03 /usr/sbin/rpc.statd -d -h -h -h -h
root   6099   0.0  0.0  14400   1780  ??  Ss    3:48PM    0:00.03 /usr/sbin/rpc.lockd -d 9 -h -h -h -h

   The server is accessed by udp in addition to tcp thus the -h
options for each address. Nfsv4 is not enabled at this time. I have
the debug output of statd & lockd running to /var/log via syslog but
nothing useful shows up.

   The interface configuration:

bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 84:2b:2b:fd:a1:fc
	inet netmask 0xffff0000 broadcast
	inet6 fe80::862b:2bff:fefd:a1fc%bce0 prefixlen 64 scopeid 0x1 
	inet netmask 0xffffffff broadcast
	inet netmask 0xffffffff broadcast
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active

   Above, a mount to works. A mount to either
or works for nfs i/o operations, but hangs for lock requests.

   I'd like this to work so I can transistion some volumes around to
different servers.

   Does anyone have any thoughts on the best way to debug this? I've looked
at what I believe are the obvious areas. I'll probably start looking more
closely at tcpdump next.


More information about the freebsd-current mailing list