File locking and system crashes

Locking prevents multiple processes from modifying the same file at the same time and allows cooperating processes to synchronize access to shared files. The user interfaces with the network locking service by way of the standard fcntl system call interface and rarely requires any detailed knowledge of how it works. The kernel maps user calls to the fcntl system call or the lockf library routine into RPC-based messages to the local lock manager. The fact that the filesystem may be spread across multiple machines is really not a complication -- until a crash occurs.

All computers crash from time to time. In an NFS environment, where multiple machines can have access to the same file at the same time, the process of recovering from a crash is necessarily more complex than in a non-network environment. First, locking is inherently stateful (it requires information about locks to be maintained on the server). If a server crashes, clients with locked files must be able to recover their locks. If a client crashes, its servers must release the locks held by processes running on the client. Second, to preserve NFS's overall transparency, the recovery of lost locks must not require the intervention of the applications themselves. This is accomplished as follows:

• Basic file access operations, such as read and write, use a stateless protocol (the NFS protocol). All interactions between NFS servers and clients are atomic -- the server doesn't remember anything about its clients from one interaction to the next. In the case of a server crash, client applications will simply sleep until the server comes back up and their NFS operations can complete.

• Stateful services (those that require the server to maintain client information from one transaction to the next), such as the locking service, are not part of the NFS itself. They are separate services that use the status monitor to ensure that their implicit network state information remains consistent with the real state of the network. There are two specific state-related problems involved in providing the locking in a network context:

  • If the client has crashed, the lock can be held forever by the server.

  • If the server has crashed, it loses its state (including all its lock information) when it recovers.

For a representation of the relationship between the lock and status managers on the server and the clients, refer to ``NFS locking manager architecture''.

NFS locking manager architecture

The following figure depicts the overall architecture of the locking service.

Architecture of the locking service over NFS