Managing NFS and NIS, 2nd Edition - Mike Eisler [135]
The second difference is that there is no advisory locking. Whole file locking, byte range locking, and share reservation locking are all mandatory or enforced.[1]
* * *
Tip
Share reservations in the Windows world do not interact at all with Windows byte range or whole file locking.
* * *
* * *
[1] As it turns out, very few Windows programs rely on byte range mandatory locking.
NFS and file locking
The NFS (Versions 2 and 3) protocol does not support file locking, but the NFS environment supports an ancillary protocol called NLM, which originally stood for "Network Lock Manager." When an NFS filesystem on an NFS client gets a request to lock a file, instead of an NFS remote procedure call, it generates an NLM remote procedure call.
The NLM protocol
The NLM protocol consists of remote procedure calls that pattern fcntl arguments and results. Because blocking locks are supported (a process blocks waiting for a lock that conflicts with another holder), the NLM protocol has the notion of callbacks, from the file server to the NLM client to notify that a lock is available. In this way, the NLM client sometimes acts as an RPC server in order to receive delayed results from lock calls.
NLM recovery
The NFS protocol is stateless, but because file locking is inherently stateful, NLM is stateful. This results in a more complex scheme to recover from failures. There are three types of recovery scenarios to consider:
Server crash
Client crash
Network partition
Server crash
When the NLM server crashes, NLM clients that are holding locks must reestablish them on the server when it restarts. The NLM protocol deals with this by having the status monitor on the server send a notification message to the status monitor of each NLM client that was holding locks. The initial period after a server restart is called the grace period. During the grace period, only requests to reestablish locks are granted. Thus, clients that reestablish locks during the grace period are guaranteed to not lose their locks.
Client crash
When an NLM client crashes, it is desirable that any locks it was holding at the time be removed from all the NLM servers it had locks on. The NLM protocol deals with this by having the status monitor on the client send a message to each server's status monitor once the client reboots. The client reboot indication tells the server that the client no longer needs its locks.
Of course, if the client crashes and never comes back to life, the client's locks will persist indefinitely. This is not good for two reasons:
Resources are indefinitely leaked.
Eventually another client will want to get a conflicting lock on at least one of the files the crashed client had locked. Thus the other client is postponed indefinitely.
This is one of the administrative issues you will need to deal with, which we will cover later in this chapter.
Network partition
Suppose an NLM client is holding a lock, but the network route between it and the NLM server goes down: a network partition. At this point, from the perspective of the server, the situation is indistinguishable from a client that crashes but never comes back. Again, this is a situation you will need to handle.
Mandatory locking and NFS
NLM supports only advisory whole file and byte range locking, and until NFS Version 4 is deployed, this means that the NFS