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:
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.
|
Copyright IBM Corporation 1990, 2014
|