Managing NFS and NIS, 2nd Edition - Mike Eisler [75]
On server toolbox:
# cd /export/home/local
# ls
bin
bin.mips bin.sun3 bin.sun4 bin.vax mansharesrc
On client:
# mount toolbox:/export/home/local /usr/local
# mount toolbox:/export/home/local/bin.`arch` /usr/local/bin
At first glance, the previous example appears to violate the NFS rules prohibiting the export of a directory and any of its subdirectories. However, there is only one exported filesystem on server toolbox, namely, /export/home. The clients mount different parts of this exported filesystem on top of one another. NFS allows a client to mount any part of an exported filesystem, on any directory.
To save disk space with the two-mount approach, populate /export/home/bin on the server with the proper executables, and make the bin.arch directory a symbolic link to bin. This allows clients of the same architecture as the server to get by with only one mount.
If you keep all executables — scripts and compiled applications — in the bin directories, you still have a problem with duplication. At some sites, scripts may account for more than half of the tools in /usr/local/bin, and having to copy them into each architecture-specific bin directory makes this solution less pleasing.
A more robust solution to the problem is to divide shell scripts and executables into two directories: scripts go in /usr/local/share while compiled executables live in the familiar /usr/local/bin. This makes share a peer of the /usr/local/man and src directories, both of which contain architecture-neutral ASCII files. To adapt to the fully architecture-neutral /usr/local/bin, users need to put both /usr/local/bin and /usr/local/share in their search paths, although this is a small price to pay for the guarantee that all tools are accessible from all systems.
There is one problem with mounting one filesystem on top of another: if the server for these filesystems goes down, you will not be able to unmount them until the server recovers. When you unmount a filesystem, it gets information about all of the directories above it. If the filesystem is not mounted on top of another NFS filesystem, this isn't a problem: all of the directory information is on the NFS client. However, the hierarchy of mounts used in the /usr/local/bin example presents a problem. One of the directories that an unmount operation would need to check is located on the server that crashed. An attempt to unmount the /usr/local/bin directory will hang because it tries to get information about the /usr/local mount point — and the server for that mount point is the one that crashed. Similarly, if you try to unmount the /usr/local filesystem, this attempt will fail because the /usr/local/bin directory is in use: it has a filesystem mounted on it.
* * *
[1] The getcwd( ) routine builds its pathname of the current working directory by searching upward via the ".." directory, and then reading each directory to find the directory with the same file ID number as the current working directory. To get the file ID requires invoking the stat( ) system call on the directory. If the directory is served by an NFS server, and the server is unavailable, then stat( ), hence getcwd( ), and the application will hang indefinitely.
[2] The example uses /users and not /home. This is because the automounter in Solaris reserves /home. While you can modify each Solaris client to remove the reservation, that is tedious. A common error is for people to use vfstab or the mount command to mount onto /home, and if the automounter has reserved /home, things will fail in odd ways.
Chapter 7. Network File System Design and Operation
It's possible to configure and use the Network File System without too much knowledge of how it is implemented or why various design decisions were made. But if you need to debug problems, or analyze patterns of NFS usage to suggest performance optimizations, you will need