Managing NFS and NIS, 2nd Edition - Mike Eisler [66]
You cannot put a mount in the background of any system-critical filesystem such as the root ( / ) or /usr filesystem on a diskless client. If you need the filesystem to run the system, you must allow the mount to complete in the foreground. Similarly, if you require some applications from an NFS-mounted partition during the boot process — let's say you start up a license server via a script in /etc/rc2.d — you should hard-mount the filesystem with these executables so that you are not left with a half-functioning machine. Any filesystem that is not critical to the system's operation can be mounted with the bg option. Use of background mounts allows your network to recover more gracefully from widespread problems such as power failures.
When two servers are clients of each other, the bg option must be used in at least one of the server's /etc/vfstab files. When both servers boot at the same time, for example as the result of a power failure, one usually tries to mount the other's filesystems before they have been exported and before NFS is started. If both servers use foreground mounts only, then a deadlock is possible when they wait on each other to recover as NFS servers. Using bg allows the first mount attempt to fail and be put into the background. When both servers finally complete booting, the backgrounded mounts complete successfully. So what if you have critical mounts on each client, such that backgrounding one is not appropriate? To cope, you will need to use the automounter (see Chapter 9) instead of vfstab to mount NFS filesystems.
The default value of the retry option was chosen to be large enough to guarantee that a client makes a sufficiently good effort to mount a filesystem from a crashed or hung server. However, if some event causes the client and the server to reboot at the same time, and the client cannot complete the mount before the retry count is exhausted, the client will not mount the filesystem even when the remote server comes back online. If you have a power failure early in the weekend, and all the clients come up but a server is down, you may have to manually remount filesystems on clients that have reached their limit of mount retries.
Hard and soft mounts
The hard and soft mount options determine how a client behaves when the server is excessively loaded for a long period or when it crashes. By default, all NFS filesystems are mounted hard, which means that an RPC call that times out will be retried indefinitely until a response is received from the server. This makes the NFS server look as much like a local disk as possible — the request that needs to go to disk completes at some point in the future. An NFS server that crashes looks like a disk that is very, very slow.
A side effect of hard-mounting NFS filesystems is that processes block (or "hang") in a high-priority disk wait state until their NFS RPC calls complete. If an NFS server goes down, the clients using its filesystems hang if they reference these filesystems before the server recovers. Using intr in conjunction with the hard mount option allows users to interrupt system calls that are blocked waiting on a crashed server. The system call is interrupted when the process making the call receives a signal, usually sent by the user typing CTRL-C (interrupt) or using the kill command. CTRL-\ (quit) is another way to generate a signal, as is logging out of the NFS client host. When using kill , only SIGINT, SIGQUIT, and SIGHUP will interrupt NFS operations.
When an NFS filesystem is soft-mounted, repeated RPC call failures eventually cause the NFS operation to fail as well. Instead of emulating a painfully slow disk, a server exporting a soft-mounted filesystem looks like a failing disk when it crashes: system calls referencing the soft-mounted NFS filesystem return errors. Sometimes the errors can be ignored or are preferable to blocking at high priority; for example, if you were doing an ls -l when the NFS server crashed, you wouldn't