Introducing Network File System Version 4 on HP-UX 11i v3

10
NOTE: ONCplus version B.11.31.03 (or later) will be included in the HP-UX 11i v3 Update 3 fusion
release planned for September 2008.
For example, if a directory, /dir, is being exported by a server, then no local processes on the server
should be accessing files in /dir. With the introduction of the delegation stackable module in
ONCplus B.11.31.03, this restriction is no longer applicable.
File Locking as part of the NFSv4 protocol
While previous versions of NFS were stateless, accompanying protocols and daemons were created
to manage things like file lock state and node status (that is, whether a node was up, rebooting, or
down). While these protocols and daemons were associated with NFS, they were not part of the core
NFS protocol. Specifically, the lock manager protocol, along with the lock and node status daemons
(rpc.lockd and rpc.statd, respectively), were created. These daemons are still present on HP-UX 11i v3
in support of NFSv2 and NFSv3 clients.
However, in Figure 5, which lists all the opcodes supported by NFSv4, there are several locking-
related opcodes: LOCK, LOCKT, and LOCKU (line 10). The LOCK, LOCKT, and LOCKU opcodes
support creating locks, testing for locks, and unlocking files, respectively. Rather than continuing to
support locking outside NFS, these opcodes were added to support locking from within the protocol.
The Ethereal trace in Figure 8 was generated by a C program that opens a file and then requests a
read lock on the first 3 bytes. The request contains the stateid associated with the file (line 18) and the
client identification (line 23). These match the state identifier granted by the OPEN opcode in Figure
7, line 15, and the client identifier granted by the SETCLIENTID opcode in Figure 4, line 11. Both are
necessary because the lock request is associated with both this client and this instance of the file’s
open.
Figure 8. LOCK opcode request