Managing NFS and NIS, 2nd Edition - Mike Eisler [113]
The staging area /tmp_mnt is a key to the indirect map mechanism. If the staging area concept is eliminated, then the indirect map mount point becomes another directory filled with direct mounts. The primary advantage of indirect maps is that they allow the mount points in a directory to be managed independently — the mounts occur when a process references the mount point, and not the parent directory itself. We'll look at some problems with direct mounts shortly.
As a result of linking /tools to the actual NFS mount point, a user would encounter the following:
% cd /tools/bin
% /usr/bin/pwd
/tmp_mnt/tools/bin
In other words, instead of pwd displaying /tools/bin, it gets /tmp_mnt/tools/bin. This behavior breaks lots of software. For example, a program might record the current working directory, and cache it in a file. A subsequent invocation of the program might read the cache, and attempt to access /tmp_mnt/tools/bin, and find that it isn't there. This is because a user-level automounter responds to attempts to access /tools, not /tmp_mnt/tools. For the remainder of this chapter, we will refer to this issue as the "pwd problem."
There are other side-effects of the user-level automounter that may catch the user off-guard. The automounter creates and controls the indirect map mount point. It emulates the entire directory, so that no user, even the superuser, can create entries in it. This has an important implication for creating indirect maps: they cannot be mounted over an existing directory, because the automounter hides the underlying files. If a directory must contain a mixture of automounter mount points and "normal" directory entries, a direct map must be used.
This is an important but subtle point: when you poke at a user-level automounter mount point with ls, it appears that there is a directory filled with symbolic links. In reality, this directory and the links in it do not exist on any disk. If this hurts to think about, it's really no different than the way NFS itself works: there may be no filesystem called /tools/news on your local disk, but NFS makes it look like it's there. The user-level automounter speaks to the NFS protocol, allowing it to fabricate replies to NFS RPC calls that are indistinguishable from the real thing.
Because the user-level automounter controls the contents of a readdir NFS RPC reply, ls behaves strangely. The user-level automounter displays only currently mounted links in the directory it emulates. If no reference is made to a subdirectory of the indirect map directory, it appears empty:
% cd /tools
% ls
% ls /tools/news
bin lib spool
% cd /tools
% ls -l
total 1
lrwxrwxrwx 1 root 19 Aug 31 12:59 news -> /tmp_mnt/tools/news
Why not display potential mounts as well? Doing so could result in a great deal of unintended mounting activity — a mount storm — when ls -l is executed in this directory. A newer automounter described in the next section allows you to browse potential mounts, as well as fix the pwd problem described earlier. Another approach is to use hierarchical mounts, as described later in this chapter.
The autofs automounter
The pwd problem described in the previous section was solved in Solaris 2.4 with the introduction of a hybrid user-level and kernel-level automounter, which retained a user-level automounter daemon, but introduced a new filesystem known as autofs. The autofs filesystem is a pseudo-filesystem that allows you to mount automounter points like /tools/news as directory objects directly underneath /tools, instead of as symbolic links. The automounter daemon is no longer an NFS server, but instead responds to requests from the in-kernel autofs filesystem to mount NFS filesystems on the mount points that autofs creates.
Let's take a look at how adding autofs changes how the automounter works using the example of the indirect auto_tools