The locking protocol

There are four basic kernel-to-lock manager (KLM) requests:

KLM_LOCK

Lock the specified record.

KLM_UNLOCK

Unlock the specified record.

KLM_TEST

Test if the specified record is locked.

KLM_CANCEL

Cancel an outstanding lock request.

• The lock manager plays an important role during system crashes. When an NFS client goes down, the lock managers on all servers are notified through their status monitors. The servers then release the client's locks, on the assumption that the client will request locks again as needed. When a server crashes, clients wait for the server to come back up. Once the server is up, its lock manager will give the client lock managers a grace period to submit lock reclaim requests; during this period, the server will accept only reclaim requests. The client status monitors will notify their respective lock managers when the server recovers. The default grace period is 45 seconds.

• It is possible that, after a server crash, a client will not be able to recover a lock that it had on a file on that server because another process may have beaten the recovering application process to the lock. In this case, the SIGLOST signal will be sent to the process (the default action for this signal is to kill the application).

• The local lock manager does not reply to the kernel lock request until the server lock manager has responded to it. Further, if the lock request is on a server new to the local lock manager, the lock manager registers its interest in that server with the local status monitor and waits for its reply. Thus, if either the status monitor or the server's lock manager is unavailable, the reply to a lock request for remote data is delayed until it becomes available.