RE: [nfsv4] questing about NLM LOCK, CANCEL UNLOCK

["Frank Filz" <ffilzlnx@mindspring.com>]

> On Thu, Dec 7, 2017 at 11:58 AM, J. Bruce Fields <bfields@fieldses.org>
> wrote:
> > On Thu, Dec 07, 2017 at 11:10:16AM -0500, Olga Kornievskaia wrote:
> >> Ok. I thought that because RFC1813 covers NLM operations that it is.
> >
> > Yeah, I don't see a harm to the occasional NLM question on the v4
> > working group list.  It's a bit of an orphaned protocol, so there's
> > not really any other implementation-independent forum.
> >
> >> I will extend this question to the Linux NFS mailing list as the
> >> client implementation I'm interested is Linux.
> >
> > But that's fine too.
> >
> > I thought that LOCK/CANCEL race was one of the motivations for NFSv4,
> > so...
> >
> >> >> Is there a solution or this is broken protocol?
> >
> > ... I'd always assumed the protocol was impossible to implement 100%
> > correctly, though maybe there's some clever solution.
> 
> Is such race still possible with the linux server implementation which is
single
> threaded and in my testing isn't processing LOCK/CANCEL out-of-order then?
> 
> >> >> Should it be client's responsibility to notice that it received a
> >> >> LOCK reply for which it wasn't waiting and always follow up with an
> UNLOCK?
> >
> > That would be tricky and still not handle all cases, I think.
> 
> Yes I'm not sure the client can do it. It will have no info about the lock
and not
> sure how to create an appropriate UNLOCK reply (unless we keep around
> lock info of all cancelled locks).

The NLM4_GRANTED call has a response where the client can respond
NLM4_DENIED to indicate it is not accepting the lock.

The Ganesha NFS server could process out of order, however, if the client
responds to the grant with NLM4_DENIED, Ganesha will properly release the
lock.

The imperfectness of NLM is why I have seen requests for tools to free
wedged locks... We haven't managed to write such a tool for Ganesha yet (so
either we don't actually have that many NLM clients, or folks are using
other mechanisms to deal with the issue - restarting the server and making
all the clients reclaim the locks they want is one way to do it...).

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus