Network File Systems

Edit online

NFS allows programs on one system to access files on another system transparently by mounting the remote directory.

Usually, when the server is booted, directories are made available by the exportfs command, and the daemons to handle remote access (nfsd daemons) are started. Similarly, the mounts of the remote directories and the initiation of the appropriate numbers of NFS block I/O daemons (biod daemon) to handle remote access are performed during client system boot.

The nfsd and biod daemons are both multithreaded, which means there are multiple kernel threads within a process. Also, the daemons are self-tuning in that they create or delete threads as needed, based on the amount of NFS activity.

The following figure illustrates the structure of the dialog between NFS clients and a server. When a thread in a client system attempts to read or write a file in an NFS-mounted directory, the request is redirected from the usual I/O mechanism to one of the client's biod threads. The biod thread sends the request to the appropriate server, where it is assigned to one of the server's NFS threads (nfsd thread). While that request is being processed, neither the biod nor the nfsd thread involved do any other work.

Figure 1. NFS Client-Server Interaction. This illustration shows two clients and one server on a network that is laid out in a typical star topology. Client A is running application thread m in which data is directed to one of its biod threads. Similarly, client B is running application thread n and directing data to one of its biod threads. The respective threads send the data across the network to server Z where it is assigned to one of the server's NFS (nfsd) threads.
NFS Client-Server Interaction

NFS uses Remote Procedure Calls (RPC) to communicate. RPCs are built on top of the External Data Representation (XDR) protocol which transforms data to a generic format before transmitting and allowing machines with different architectures to exchange information. The RPC library is a library of procedures that allows a local (client) process to direct a remote (server) process to execute a procedure call as if the local (client) process had executed the procedure call in its own address space. Because the client and server are two separate processes, they no longer have to exist on the same physical system.

Figure 2. The Mount and NFS Process. This illustration is a three column table with Client Activity, Client, and Server as the three column headings. The first client activity is mount. An RPC call goes from the client to the server's portmapper mountd. The second client activity is open/close read/write. There is two-way interaction between the client's biod thread and the server's nfsd thread.
The Mount and NFS Process

The portmap daemon, portmapper, is a network service daemon that provides clients with a standard way of looking up a port number associated with a specific program. When services on a server are requested, they register with portmap daemon as an available server. The portmap daemon then maintains a table of program-to-port pairs.

When the client initiates a request to the server, it first contacts the portmap daemon to see where the service resides. The portmap daemon listens on a well-known port so the client does not have to look for it. The portmap daemon responds to the client with the port of the service that the client is requesting. The client, upon receipt of the port number, is able to make all of its future requests directly to the application.

The mountd daemon is a server daemon that answers a client request to mount a server's exported file system or directory. The mountd daemon determines which file system is available by reading the /etc/xtab file. The mount process takes place as follows:

  1. Client mount makes call to server's portmap daemon to find the port number assigned to the mountd daemon.
  2. The portmap daemon passes the port number to the client.
  3. The client mount command then contacts the server mountd daemon directly and passes the name of the desired directory.
  4. The server mountd daemon checks /etc/xtab (built by the exportfs -a command, which reads /etc/exports) to verify availability and permissions on the requested directory.
  5. If all is verified, the server mountd daemon gets a file handle (pointer to file system directory) for the exported directory and passes it back to the client's kernel.

The client only contacts the portmap daemon on its very first mount request after a system restart. Once the client knows the port number of the mountd daemon, the client goes directly to that port number for any subsequent mount request.

The biod daemon is the block input/output daemon and is required in order to perform read-ahead and write-behind requests, as well as directory reads. The biod daemon threads improve NFS performance by filling or emptying the buffer cache on behalf of the NFS client applications. When a user on a client system wants to read from or write to a file on a server, the biod threads send the requests to the server. The following NFS operations are sent directly to the server from the operating system's NFS client kernel extension and do not require the use of the biod daemon:

  • getattr()
  • setattr()
  • lookup()
  • readlink()
  • create()
  • remove()
  • rename()
  • link()
  • symlink()
  • mkdir()
  • rmdir()
  • readdir()
  • readdirplus()
  • fsstat()

The nfsd daemon is the active agent providing NFS services from the NFS server. The receipt of any one NFS protocol request from a client requires the dedicated attention of an nfsd daemon thread until that request is satisfied and the results of the request processing are sent back to the client.