[NFS-Ganesha-Support] Re: NFSv3 NLM service conflict with linux kernel client

On 10/26/21 2:52 AM, Olivier Garaud via Support wrote: > Hi, > > Do you know if there is a workaround to the NLM problem we can > experience when a client is running on the same host as Ganesha ? > > The linux kernel lock manager registers NLM to the portmapper > overriding the registration done by ganesha. > A more complete description of the problem can be found here: > https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-n... > < https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-n... > §NFS client or application hang due to NLM locks. > There is no solution to this. The fact that an NLM client MUST ALSO be an NLM server, and port mapper/rpcbind only allows a single registration for a given RPC program/protocol leaves us no option. Even replacing rpcbind with something built into Ganesha, something I've considered to allow single node NLM testing, would have very limited capability. It could work in the test environment, because Ganesha would never make portmapper calls, it would just check what the kernel "registration" was and use that to reply to the kernel client, while the kernel client would make portmapper calls which Ganesha would respond to with it's NLM port. Externally, it could only work if you configured remote addresses as either Ganesha clients or as NFS servers (actually you COULD have both kernel NFS server AND Ganesha NFS server this way - the remote addresses configured as NFS servers could also be kernel NFS server clients since the two lockds are allowed to talk to each other. While I have long dreamed of this, the practical use is limited so I have never put the effort in. Frank _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org