|
|
At each server site, a lock manager process accepts lock requests on behalf of client processes by a remote lock manager or on behalf of local processes by the kernel. The client and server lock managers communicate with RPCs. Upon receiving a remote lock request for a machine that it doesn't already hold a lock on, the lock manager registers its interest in that machine with the local status monitor and waits for that monitor to notify it that the machine is up. The monitor continues to watch the status of registered machines and notifies the lock manager if one of them is rebooted (after a crash). If the lock request is for a local file, the lock manager tries to satisfy it and communicates back to the application along with the appropriate RPC path.
The crash recovery procedure is very simple. If the failure of a client is detected, the server releases the failed client's locks, on the assumption that the client application will request locks again as needed. If the recovery (and, by implication, the crash) of a server is detected, the client lock manager retransmits all the lock requests previously granted by the recovered server. The server uses this retransmitted information to reconstruct its locking state.
The locking service, then, is essentially stateless; or to be more precise, its state information is carefully circumscribed within a pair of system daemons that are set up for automatic application-transparent crash recovery. If a server crashes, and thus loses its state, it expects that its clients will be notified of the crash and that they will send it the information it needs to reconstruct its state. The key in this approach is the status monitor, which the lock manager uses to detect both client and server failures.
For more information about the lock manager daemon, see the lockd(1Mnfs) manual page.