Processes that work on shared files use locks to synchronize accesses to these files. Locks on files or file areas (records) are set, released or queried with the fcntl() system call. The NFS protocol does not support the setting of locks because it is created as a "stateless" entity: if the NFS client triggers an action on the server, this action does not generate a state on the server that would be lost if the server crashed. For this reason, either
no state is generated on the server (e.g. when reading data), or
a "permanent" state is generated on the server (e.g. when creating or deleting files); permanent states continue to exist even after a server crash
From the point of view of an NFS client, a server that restarts following a crash merely appears to be a server that operates very slowly. Similarly, a client that restarts after a crash simply appears to the NFS server as a client that has not sent any requests for a long time. This convenient restart procedure makes NFS very robust and is due to the statelessness of the NFS protocol.
However, it is not possible to set locks with a stateless protocol. Locks must be registered with the NFS server and are lost if the server crashes (unless each lock is saved in non-volatile storage). Working with locks on an NFS is thus implemented in a separate "NLM" (Network Lock Manager) protocol. Only "advisory" locks are supported by the Network Lock Manager. This means that the locks are only effective when all user programs work with locks for accessing the respective files or file sections. The lockdsrv program implements the NLM protocol on the server side. NLM is implemented in the system kernel on the client. Nevertheless, the client still relies on the help services provided by the lockdclnt process running on the client.
When working with locks using NFS, it must be ensured that the client processes buffer every access to a shared file. When NFS locks are set, the NFS client does not buffer read and write data. However, if both unbuffered and buffered accesses are used (e.g. those performed before any locks were set), the consistency of shared files can no longer be guaranteed. Exception: all client processes are working on the same client computer (i.e. are also sharing the buffer).
If an NLM client or server fails, cleanup actions must be started on the respective partner when the client or server restarts. A server must delete all the locks of a restarting client; a client must again set its locks if the server restarts, in order to restore the status in place before the server crashed.
Restart actions may be required for some status-based network services. These actions are thus registered with a service independent of NLM, known as the NSM (Network Status Monitor). The NSM then ensures that the relevant actions are performed when a crashed partner restarts. The NSM protocol is implemented in the statd program. At present, the NLM (lockdsrv, lockdclnt) is the only service that uses the NSM (statd). See also the description of lockdsrv and lockdclnt in the section "Daemons".