The NFS environment provides transparent file access to remote files over a network. File systems of remote devices appear to be local. Clients access remote file systems by using either the mount command or the automounter.
The NFS protocol enables multiple client retries and easy crash recovery. The client provides all of the information for the server to perform the requested operation. The client retries the request until it is acknowledged by the server, or until it times out. The server acknowledges writes when the data is flushed to nonvolatile storage.
The multithreaded kernel does not require the maintenance of multiple nfsd or asynchronous-block I/O daemon(biod) processes; they are both implemented as operating system kernel threads. There are no biods on the client and one nfsd process exists on the server.
NFS traffic is characterized by its random patterns. NFS requests, which are usually of many types, are generated in bursts. The capacity of an NFS server must address the bursty nature of NFS file service demands. Demand varies widely but is relatively predictable during normal activity.
Most requests from applications (which may be local or remote), follow this pattern:
The user reads in the sections of the application binary then executes the code pages leading to a user dialog, which specifies a data set on which to operate.
The application reads the data set from the remote disk.
The user can then interact with the application, manipulating the in-memory representation of the data. This phase continues for most of the runtime of the application.
The modified data set is saved to disk.
More sections of the application binary may be paged in as the application continues to run.