Background Concepts

When NFS was developed there were many problems with the stability of networks and servers. NFS was designed to be an efficient protocol that could successfully handle an unstable environment without causing harm to the client machine. To operate in such a potentially harsh environment, NFS was built to be stateless. Being stateless means that there is no "state" that any operation could hold NFS in. For instance, in NFS version 2, when you perform a write, it will not return a result until the data has been written onto permanent storage. If the write never returns, it is up to the client to decide to continue waiting for the write to finish, or to not make the write.

So being stateless means that the server can crash and the client will wait for the server to come back up. However, for some technical reasons as we'll explain below, there can be minor problems. The most notable one is the "Stale File Handle" error that can be seen after a server is rebooted. The cause of this one is, related to the file handles that the server uses with its filesystem. If those should change, then NFS mounts that the client will not have the correct filehandle and it will need to be unmounted and then remounted.

Under the Covers, Its All Filehandles

So, let's take a closer look at how NFS works. Understanding the internals of the NFS protocol sheds light on how it will react during operation. NFS operates by assigning filehandles to all of the files and directories that will be shared by the NFS resource. However, this is not quite as difficult as it sounds. These filehandles that NFS uses are simply the exact same ones that the Unix kernel assigns to the files and directories on the hard drive. Hence, all the NFS server is doing is reusing these filehandles for simplicity. So when your NFS client has an open file on an NFS partition, the filehandle that the NFS client uses with the NFS server is the exact same one that the NFS server uses with its Unix (or other variant) kernel.

This is important because if you have ever spent much time with NFS, you most likely have seen the error, "Stale File Handle". This isn't talking about potato chips, but rather that the filehandle that your NFS client has gotten from its NFS server is no longer valid, and the mount will need to be re-established. Why does this happen? The filehandles are derived from many things that are unique to each setup of a server. Unix filehandles, for instance, are based on major and minor numbers of devices, which are derived from SCSI addresses, the respective SCSI cards, and often other system-specific things. So if you change around the SCSI addresses on your machine, you will most likely also need to have your NFS clients unmount and then re-mount the NFS shares.

How Does It Work?

Well, beyond the business of filehandles, there is the entire protocol of how the NFS clients and servers actually talk to each other. The main parts of the communication between the client are the nfs client software, and the portmapper, the mountd and the NFSd on the server. There are four main steps to getting an NFS mount to happen. Lets say that there is an NFS server that is exporting /users/ballard/, and that we are looking for /users/ballard/schedule.doc:

1. The client software asks the server's portmapper, "Hello NFS server, what port number can I find mountd at?" To which the server replies, "Hello NFS client, please ask on port number 923." Now, the NFS client knows that if it wants to mount (use an NFS share) something, it will need to ask the mountd on port 923 for it.

2. The NFS client then asks the mountd "Hello NFS mountd, what is the filehandle for export: /users/ballard?" The server responds with the filehandle.

3. With this filehandle, the client then asks the portmapper for the NFS port "Hello portmapper, what is the NFSd that is to be used with /users/ballard?" The server responds with the port number assigned to it.

4. The NFS client then contacts the server's NFSd on the port it received in step 3, and says "Here is the filehandle, and I'm looking for schedule.doc" The NFSd replies with the filehandle for the object.

The remote NFS system can now talk with the NFSd and can perform file operations using the provided filehandle.

The Stateless File system

What makes NFS such a powerful file protocol is that it is stateless. Being stateless means that at no time do either the client or server go into a state that depends on further information. This means that either the NFS client or the NFS server can physically reboot, and once restarted, the communications can happen again.