NFS and file locking (Managing NFS and NIS, 2nd Edition)

Book Home

Previous

Next

11.2. 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.

11.2.1. 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.

11.2.2. 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

11.2.2.1. 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.

11.2.2.2. 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.

11.2.2.3. 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.

11.2.3. 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 environment cannot support mandatory whole file and byte range locking. The reason goes back to how mandatory locking interacts with advisory fcntl calls.

Let's suppose a process with ID 1867 issues an fcntl exclusive lock call on the entire range of a local file that has mandatory lock permissions set. This fcntl call is an advisory lock. Now the process attempts to write the file. The operating system can tell that process 1867 holds an advisory lock, and so, it allows the write to proceed, rather than attempting to acquire the advisory lock on behalf of the process 1867 for the duration of the write. Now suppose process 1867 does the same sequence on another file with mandatory lock permissions, but this file is on an NFS filesystem. Process 1867 issues an fcntl exclusive lock call on the entire range of a file that has mandatory lock permissions set. Now process 1867 attempts to write the file. While the NLM protocol has fields in its lock requests to uniquely identify the process on the client that locked the file, the NFS protocol has no fields to identify the processes that are doing writes or reads. The file is advisory locked, and it has the mandatory lock permissions set, yet the NFS server has no way of knowing if the process that sent the write request is the same one that obtained the lock. Thus, the NFS server cannot lock the file on behalf of the NFS client. For this reason, some NFS servers, including Solaris servers, refuse any read or write to a file with the mandatory lock permissions set.

11.2.4. NFS and Windows lock semantics

The NLM protocol supports byte range locking and share reservations.

While Windows byte range locking is mandatory, on Unix servers it will be advisory. To the dismay of Windows software developers, this means that non-PC/NFS clients might step on PC/NFS clients, because the non-PC/NFS client does not try to acquire a lock. It also means that servers that support both NFS/NLM and SMB might not correctly handle cases where an NFS client is doing a read or write to a file that an SMB client has established a mandatory lock on.

PC/NFS clients will emulate share reservation semantics by issuing the share reservation remote procedure calls to the NLM server. However, most non-PC/NFS clients, or even local processes on Unix NLM servers will not honor the deny semantics of the share reservation of the PC/NFS client. Another problem with the emulation is that Windows semantics expect the share reservation and exclusive file creation to be atomic. The share reservation and file creation go out as separate operations, hence no atomicity, allowing a window of vulnerability, where a client can succeed in its exclusive create, but not get the share reservation.