z/OS Network File System Guide and Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


NFS version 4 state

z/OS Network File System Guide and Reference
SC23-6883-00

The NFS version 4 protocol introduces state information that allows clients and servers to keep track of certain resources.

NFS version 4 uses a value of clientid or stateid to represent the current state (instance) of client-held resources such as locks, opens, and host restarts. The client and server pass this state information between them on certain operations, allowing both to agree on the current instance of resources held by the client.

NFS version 4 includes new states for the following:

  1. Client/Server restart instance
  2. Open Share/Deny instance
  3. Byte Range Locks instance
  4. Client Delegation instance.

The NFS version 4 state that is passed between the client and server represents a single instance in a dynamically changing environment; it is incremented when a state is changed within a group of held resources (restart, open, or lock). Once state is established on the server, the client returns what it believes is the current state. The server compares the client state to the server state to detect stale and out of order requests.

The client uses the setclientid operation to notify the server of its intention to use a particular client identifier for subsequent requests that entail creating lock, share reservation, and delegation state on the server. Upon successful completion the server returns a shorthand clientid , which, if confirmed in a separate step, will be used in subsequent file locking and file open requests. Confirmation of the clientid must be done using the setclientid_confirm operation to return the clientid and setclientid_confirm values, as verifiers, to the server.

NFS version 2 and version 3 used the Network Status Monitor (NSM) protocol to determine if resources such as file open share or byte range locks were still in use by a remote client. NFS version 4 no longer uses NSM to communicate a client or server restart. NFS version 4 instead uses a current state on both the client and server, where the state is established and passed in subsequent NFS version 4 operations.

In NFS versions 2 and 3, a client or server issues an NSM sm_notify RPC procedure to notify the remote host of a restart. Server resources such as an exclusive byte range lock on a file might remain held until explicitly released by the client. If a client that holds a server resource is removed from the network for a long period without the server being notified, the server resource would be unavailable to other clients until timed out by the server.

NFS version 4 provides a protocol for the client to establish or reestablish state, and associates ownership of subsequent server stateful operations to previously established states. To resolve the absent client problem, the NFS version 4 client must routinely refresh the state within the server-specified lease time. Upon lease time-out, the server may release resources for the client and make them available to other applications.
  • A client obtains the server-specified lease time-out attribute by issuing a getattr operation. getattr is not a stateful operation, thus it does not require prior state to be established. A getattr operation may precede a setclientid or setclientid_confirm operation.
  • Refer to the NFS server's leasetime site attribute for setting and tuning lease time periods.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014