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-nfs-ganesha.html
> <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-ganesha.html>
> §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@lists.nfs-ganesha.org
To unsubscribe send an email to support-leave@lists.nfs-ganesha.org