My understanding is NFSv4 clients should immediately connect to the NFSv4 service on the server, skipping the rpcbind portmapper and mountd service interactions entirely, but I'm seeing my RHEL6 client always first contacting the rpcbind service to get the mountd port, getting the list of export form mountd, then finally connecting to the NFSv4 service. Observed using tcpdump.
By all indications (output of mount command and inspection of TCP), when the mount operation is completed the client and server are use NFSv4.
This happens even when I do everything I've come across to try to force only NFSv4 on the client. Examples:
- Setting Nfsvers=4 in /etc/nfsmount.conf
- Explicitly mounting with vers=4 option
- Explicitly set the NFS port. (via mount command and in nfsmount.conf)
Am I completely off base or is something not right? This is a problem for me because the NFS client insists on being able to reach rpcbind on the server via UDP before it will mount any NFSv4 exports and I'm getting mysterious UDP packet loss (yes, I'm working with the network guy on this front) that is causing the mounts to fail entirely from time to time or just take a long time to complete.
I took a look at the libtirpc source and see something about it always using UDP to connect to the RPC portmapper, but I want to take the portmapper and mountd service out of the equation entirely.
I tried un-registering the UDP portmapper service on the NFS server using "rpcinfo -d", but that results in all NFS mounts targeting that server to fail (again clients insist on the server having rpcbind listening on UDP port 111). I also tried messing with /etc/netconfig with no luck.
Anyone come across this behavior or know enough about NFSv4 to tell me I have unrealistic expectations?