Hi,
If the standard for lockd is described in
http://www.opengroup.org/onlinepubs/009629799/chap9.htm#tagcjh_10,
then the linux lockd breaks the standard in numerous parts, mainly
- the protocole structures aren't the same (because on linux the structure used
is file_lock)
- lockd doesn't responds with the right message type for granted locks (more
precisely it uses a GRANTED_MSG in cases it should use GRANTED).
I have no problem with breaking the standard per se, and I fully understand the
reasons behind that, however it seems to me that it should lead to
interoperability issues. Does it ? According to the nfs howto (but it is an old
one there isn't such issues. Does it means that other nfs implementation also
use the file_lock structure ?
Pat
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Dumas Patrice <[email protected]> writes:
> Hi, If the standard for lockd is described in
> http://www.opengroup.org/onlinepubs/009629799/chap9.htm#tagcjh_10,
> then the linux lockd breaks the standard in numerous parts,
> mainly
> - the protocole structures aren't the same (because on linux
> the structure used
> is file_lock)
I don't follow you at all here. Examples please of where this is a
problem with the standard?
> - lockd doesn't responds with the right message type for
> granted locks (more
> precisely it uses a GRANTED_MSG in cases it should use
> GRANTED).
See the comment about HP clients above nlmsvc_grant_blocked().
Of course, if you are planning on writing proper support for the
asynchronous RPC, then we can indeed go ahead and make
nlmsvc_grant_blocked() call either NLM_GRANTED or NLM_GRANTED_MSG
depending on whether the client originally called NLM_LOCK or
NLM_LOCK_MSG.
Cheers,
Trond
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
> I don't follow you at all here. Examples please of where this is a
> problem with the standard?
There is a problem with my sillyness. I didn't read the sources carefully, I
found all the relevant piece now, sorry for the bothering.
> See the comment about HP clients above nlmsvc_grant_blocked().
I saw it, and I think the associated hack do things quite well.
> Of course, if you are planning on writing proper support for the
> asynchronous RPC, then we can indeed go ahead and make
> nlmsvc_grant_blocked() call either NLM_GRANTED or NLM_GRANTED_MSG
> depending on whether the client originally called NLM_LOCK or
> NLM_LOCK_MSG.
That was what I was thinking about, maybe with a fallback to NLM_GRANTED_MSG
when some time has passed, to get around HP clients (in case the original call
was with NLM_LOCK). I don't know if this happen in real life, but we could
imagine some client processing only NLM_GRANTED callbacks if they send NLM_LOCK
or maybe totally lacking support for NLM_GRANTED_MSG and the like.
Pat
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs