Managing NFS and NIS, 2nd Edition - Mike Eisler [67]
The other side to this "failing disk" analogy is that you never want to write data to an unreliable device, nor do you want to try to load executables from it. You should not use the soft option on any filesystem that is writable, nor on any filesystem from which you load executables. Furthermore, because many applications do not check return value of the read(2) system call when reading regular files (because those programs were written in the days before networking was ubiquitous, and disks were reliable enough that reads from disks virtually never failed), you should not use the soft option on any filesystem that is supplying input to applications that are in turn using the data for a mission-critical purpose. NFS only guarantees the consistency of data after a server crash if the NFS filesystem was hard-mounted by the client. Unless you really know what you are doing, neveruse the soft option.
We'll come back to hard- and soft-mount issues in when we discuss modifying client behavior in the face of slow NFS servers in Chapter 18.
Resolving mount problems
There are several things that can go wrong when attempting to mount an NFS filesystem. The most obvious failure of mount is when it cannot find the server, remote filesystem, or local mount point. You get the usual assortment of errors such as "No such host" and "No such file or directory." However, you may also get more cryptic messages like:
client# mount orion:/export/orion /hosts/orion
mount: orion:/export/orion on /hosts/orion: No such device.
If either the local or remote filesystem was specified incorrectly, you would expect a message about a nonexistent file or directory. The device hint in this error indicates that NFS is not configured into the client's kernel. The device in question is more of a pseudo-device — it's the interface to the NFS vnode operations. If the NFS client code is not in the kernel, this interface does not exist and any attempts to use it return invalid device messages. We won't discuss how to build a kernel; check your documentation for the proper procedures and options that need to be included to support NFS.
Another cryptic message is "Permission denied." Often this is because the filesystem has been exported with the options rw=client_list or ro=client_list and your client is not in client_list. But sometimes it means that the filesystem on the server is not exported at all.
Probably the most common message on NFS clients is "NFS server not responding." An NFS client will attempt to complete an RPC call up to the number of times specified by the retrans option. Once the retransmission limit has been reached, the "not responding" message appears on the system's console (or in the console window):
NFS server bitatron not responding, still trying
followed by a message indicating that the server has responded to the client's RPC requests:
NFS server bitatron OK
These "not responding" messages may mean that the server is heavily loaded and cannot respond to NFS requests before the client has had numerous RPC timeouts, or they may indicate that the server has crashed. The NFS client cannot tell the difference between the two, because it has no knowledge of why its NFS RPC calls are not being handled. If NFS clients begin printing "not responding" messages, a server have may have crashed, or you may be experiencing a burst of activity causing poor server performance.
A less common but more confusing error message is "stale filehandle." Because NFS allows multiple clients to share the same directory, it opens up a window in which one client can delete files or directories that are being referenced by another NFS client of the same server. When the second client goes to reference the deleted directory, the NFS server can no longer find it on disk, and marks the handle, or pointer, to this directory "invalid." The exact causes of stale filehandles and suggestions for avoiding them are described in Section 18.8.
If there is a problem with the