Fw: Linux/KDE and NFS locking on 7-stable

[Rick Macklem]

On Fri, 18 Sep 2009, Gerrit Kühn wrote:

>
> ???
> My NFS-Clients are accessing the server via a NAT router. There is no way
> the server could contact the clients.
>
First off, I'll note that I'm not particularily familiar with the NLM
and NSM protocols, so take all of this with a grain of salt.
My understanding is:
- The server calls does a callback to the client when a blocking lock
   can be granted, if there was a conflicting lock held at the time of
   the lock request.

- The NSM protocol tries to determine when machines have crashed. When
   a server reboots it will try to notify clients that it has rebooted.
   (I don't know the protocol well enough to know if there is any
    other time the server needs to be able to contact the client.)

> RM> I believe setting the following in the server's /etc/rc.conf
> RM> and rebooting the server (or just killing off lockd on the server),
> RM> combined with "nolock" as you have on the above Linux mount, might
> RM> work ok:
> RM>  	rpc_lockd_enable="NO"
> RM>  	rpc_statd_enable="NO"
>
> I did not try that so far, as there are some clients which seem to work
> fine with locking.
>
> RM> Imo, the nlm protocol was poorly designed and has always resulted in
> RM> interoperability problems. Although I fiddle with NFS, I avoid the NLM
> RM> like the plague:-)
>
> Seems so. Why would one want to have a server contact a client anyway? :-)
For locking correctness, I would agree. For NFSv4, locking should work
correctly without a callback network path. For blocking locks, the client
must retry the lock request until it succeeds. For recovery, the client
discovers that the server has rebooted via error codes returned from the
server for open/byte range lock operations.

My issues w.r.t. the NLM are:
- For the blocking lock, the client is depending on the server to do a
   callback to let it know when it has the lock. Beyond your NAT case,
   there are issues related to network partitioning, server crashes,...
- It also depends on the NSM to notify it that a server/client has
   crashed, rebooted, been network partitioned,...
   (my understanding of it is that a machine basically sends a notify of
    state to other machines that it thinks cares. If the messages get
    lost...)

> Yesterday I played around with it some more, and have a solution now (at
> least I hope so :-) with combining "nolock" with "tcp" on the client side.
> I read some oder mails (from you?) here that stated problems with the new
> server and strange combinations of mounting via udp and accessing via tcp
> (although I did not look up what the Linux clients actually do).
> Before I had either no protocol setting for the clients or they were
> explicitely using udp (because that solved the problems I had with locking
> when I was still using 7.0-stable :-).
>
> RM> Good luck with it, rick
> RM> ps: If you need to run the lockd on the server, starting the lockd in
> RM>      the Linux client might help, although I'd still use "nolock" on
> RM>      the Linux mount.
>
> I think statd is running on the Linux client anyway. Will have to look for
> lockd. Thanks for the hints. I still wonder a bit why nfs/locking is often
> so much of a hassle. Shouldn't it be some kind of established standard
> technique after all the years? Not that I would want to use smb instead,
> but still... btw: are there any alternatives?
>
NFSv2 and 3 are stateless server protocols (no state to recover after a
server crash/reboot) and since file locking is by definition "state",
there was no locking support. Sun added the separate protocols NLM and 
NSM to provide locking support for NFS mounted volumes. These were
all that was available prior to NFSv4 (which has integrated byte range 
locking and is not a stateless server). Beyond the fact that I think they 
were poorly designed protocols, they weren't well published. The only 
description I am aware of is in "Protocols for X/Open Internetworking: 
XNFS, Issue 4", which I had to buy for around $75 in 1993. I don't know if 
it has ever been put online and even it didn't describe the semantics very 
well, imho. (This delay in publication combined with my opinion on the
protocols was why I never implemented them.)

rick