IV82755: NFSV3 BYTE RANGE LOCKING DOESN'T WORK WITH PROTOCOL NODE AFTER MOUNTING TO ANOTHER SERVER

APAR status

• Closed as documentation error.

Error description

• A protocol node running "ganesha" is an
  NFS server, and it should NOT mount other
  NFS shares from anywhere else.
  
  When they do, what happens is that kernel
  lockd becomes active which leads to NFSv3
  byte range locking conflict issues between
  the NFS kernel and ganesha.
  
  If someone really needs to mount an NFSv3
  mount from a protocol node, they could do
  "mount -o nolock".
  

Local fix

• use mount -o nolock
  

Problem summary

• The following has been updated in the Spectrum Scale 4.2.1
  manuals:
  
  Linux kernel NFS server and client, they both use the same lockd
   daemon, so it is possible to to provide NFS services as well as
   mount an NFS file system on the same system with kernel NFS.
  Ganesha has its own lock service, so when someone mounts an NFS
  file system, the linux kernel lockd registers with rpcbind
  causing the ganesha lock service ineffective. This only applies
  to NFSv3 environments as there is no separate lock/NLM service
  in NFSv4.
  

Problem conclusion

• The following has been updated in the Spectrum Scale 4.2.1
  manuals:
  
  Linux kernel NFS server and client, they both use the same lockd
   daemon, so it is possible to to provide NFS services as well as
   mount an NFS file system on the same system with kernel NFS.
  Ganesha has its own lock service, so when someone mounts an NFS
  file system, the linux kernel lockd registers with rpcbind
  causing the ganesha lock service ineffective. This only applies
  to NFSv3 environments as there is no separate lock/NLM service
  in NFSv4.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels