NFSv3 NLM service conflict with linux kernel client
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-... §NFS client or application hang due to NLM locks. Thanks for your help, Olivier
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-... <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
Thanks for sharing this. Olivier On Tue, Oct 26, 2021 at 3:35 PM Frank Filz <ffilz@redhat.com> wrote:
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-...
< 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
On 10/26/21 7:02 AM, Olivier Garaud wrote:
Thanks for sharing this.
You're welcome. I've been thinking about this problem for many years... Frank
On Tue, Oct 26, 2021 at 3:35 PM Frank Filz <ffilz@redhat.com <mailto:ffilz@redhat.com>> wrote:
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-... <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-ganesha.html>
> <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-... <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 <mailto:support@lists.nfs-ganesha.org> To unsubscribe send an email to support-leave@lists.nfs-ganesha.org <mailto:support-leave@lists.nfs-ganesha.org>
As the local client is only used for testing purposes, I will force the nolock option with /etc/nfsmount.conf. This should avoid some errors in prod. Olivier On Tue, Oct 26, 2021 at 4:19 PM Frank Filz <ffilz@redhat.com> wrote:
On 10/26/21 7:02 AM, Olivier Garaud wrote:
Thanks for sharing this.
You're welcome. I've been thinking about this problem for many years...
Frank
On Tue, Oct 26, 2021 at 3:35 PM Frank Filz <ffilz@redhat.com <mailto:ffilz@redhat.com>> wrote:
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-...
<
https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-...
> <
https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-...
<
https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-...
> §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 <mailto:support@lists.nfs-ganesha.org> To unsubscribe send an email to support-leave@lists.nfs-ganesha.org <mailto:support-leave@lists.nfs-ganesha.org>
On 10/26/21 8:57 AM, Olivier Garaud via Support wrote:
As the local client is only used for testing purposes, I will force the nolock option with /etc/nfsmount.conf. This should avoid some errors in prod.
Yes, -onolock is what I do when I want to use a localhost NFSv3 client. Frank
On Tue, Oct 26, 2021 at 4:19 PM Frank Filz <ffilz@redhat.com <mailto:ffilz@redhat.com>> wrote:
On 10/26/21 7:02 AM, Olivier Garaud wrote: > Thanks for sharing this. > You're welcome. I've been thinking about this problem for many years...
Frank
> On Tue, Oct 26, 2021 at 3:35 PM Frank Filz <ffilz@redhat.com <mailto:ffilz@redhat.com> > <mailto:ffilz@redhat.com <mailto:ffilz@redhat.com>>> wrote: > > 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-... <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-ganesha.html> > <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-... <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-ganesha.html>> > > > > <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-... <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-ganesha.html> > <https://ganltc.github.io/problem-determination-guide-for-spectrum-scale-nfs-... <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 <mailto:support@lists.nfs-ganesha.org> > <mailto:support@lists.nfs-ganesha.org <mailto:support@lists.nfs-ganesha.org>> > To unsubscribe send an email to > support-leave@lists.nfs-ganesha.org <mailto:support-leave@lists.nfs-ganesha.org> > <mailto:support-leave@lists.nfs-ganesha.org <mailto:support-leave@lists.nfs-ganesha.org>> >
_______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
participants (2)
-
Frank Filz -
Olivier Garaud