Managing NFS and NIS, 2nd Edition - Mike Eisler [70]
# ln -s /minnow/fred /u/fred
# ln -s /alewife/lucy /u/lucy
The unsuspecting user tries to use the path-compressed names, but finds that relative pathnames aren't relative to the link directory:
% cd /u/fred
% cd ../lucy
../lucy: No such file or directory
A user may be bewildered by this behavior. According to the /u directory, fred and lucy are subdirectories of a common parent. In reality, they aren't. The symbolic links hide the real locations of the fred and lucy directories, which do not have a common parent. Using symbolic links to shorten pathnames in this fashion is not always the most efficient solution to the problem; NFS mounts can often be used to produce the same filesystem naming conventions.
Mount points, exports, and links
Symbolic links have strange effects on mounting and exporting filesystems. A good general rule to remember is that filesystem operations apply to the target of a link, not to the link itself. The symbolic link is just a pointer to the real operand.
If you mount a filesystem on a symbolic link, the actual mount occurs on the directory pointed to by the link. The following sequence of operations produces the same net result:
# mkdir -p /users/hal
# ln -s /users/hal /usr/hal
# mount bitatron:/export/home/hal /usr/hal
as this sequence does:
# mkdir -p /users/hal
# mount bitatron:/export/home/hal /users/hal
# ln -s /users/hal /usr/hal
The filesystem is mounted on the directory /users/hal and the symbolic link /usr/hal has the mount point as its target. You should make sure that the directory pointed to by the link is on a filesystem that is mounted read/write and that performing the mount will not obscure any required filesystem underneath the symbolic link target.
Exporting a symbolic link from a server follows similar rules. The filesystem or subtree of a filesystem that is really exported is the one pointed to by the symbolic link. If the parent of the link's target has already been exported, or a subtree of it is exported, the attempt to export the link fails.
More interesting than exporting a symbolic link is mounting one from the server. Mounting a link from a server is not the same thing as mounting a filesystem containing a symbolic link. The latter means that there is a symbolic link somewhere in the filesystem mounted using NFS. The former case implies that the server pathname used to locate the remote filesystem is a link and directs the mount somewhere else. The client mounts the directory pointed to by the link. As shown in Figure 6-1, if /usr/man is a symbolic link to /usr/share/man, then this mount command:
# mount bitatron:/usr/share/man /mnt
does the same thing as this mount command:
# mount bitatron:/usr/man /mnt
Figure 6-1. Mounting a server's symbolic link
A potential problem arises if the symbolic link and the directory it points to are on different filesystems: it's possible that the server has exported the link's filesystem but not the filesystem containing the link's target. In this example, /usr/man and /usr/share/man could be in two distinct filesystems, which would require two entries in the server's dfstab file.
Replication
Solaris 2.6 introduced the concept of replication to NFS clients. This feature is known as client-side failover. Client-side failover is useful whenever you have read-only data that you need to be highly available. An example will illustrate this.
Suppose your user community needs to access a collection of historical data on the last 200 national budgets of the United States. This is a lot of data, and so is a good candidate to store on a central NFS server. However, because your users' jobs depend on it, you do not want to have a single point of failure, and so you keep the data on several NFS servers. (Keeping the data on several NFS servers also gives one the opportunity to load balance). Suppose you have three NFS servers, named hamilton, wolcott, and dexter, each exporting a copy of data. Then each server might have an entry like this in its dfstab file: