We have made substantial alterations to au_lookuppn(), and slight alterations to rfscall(), nfs_mount(), nfs_unmount() and copen(). We added two new system calls: one for controlling and querying the added structures in the kernel, and the other for debugging. Finally, we added fields to three major kernel data structures: vnode and vfs structures and the open file table.
A service is named by the combination of its transport service (e.g., TCP), its well-known port number as listed in /etc/services, and an arbitrary string that has meaning to the service. Since we search for an NFS-mountable file system, our RLP request messages contain information such as the NFS transport protocol (UDP ), port number (2049) and service-specific information such as the name of the root of the file system.
Amd operates by mimicking an NFS server. An Amd process is identified to the kernel as the ``NFS server'' for a particular mount point. The only NFS calls for which Amd provides an implementation are those that perform name binding: lookup, readdir, and readlink. Since a file must have its name resolved before it can be used, Amd is assured of receiving control during the first use of any file below an Amd mount point. Amd checks whether the file system mapped to that mount point is currently mounted; if not, Amd mounts it, makes a symbolic link to the mount point, and returns to the kernel. If the file system is already mounted, Amd returns immediately.
An example, taken from our environment, of Amd's operation is the following. Suppose /u is designated as the directory in which all user file systems live; Amd services this directory. At startup time, Amd is instructed that the mount point is /n. If any of the three name binding operations mentioned above occurs for any file below /u, then Amd is invoked. Amd consults its maps, which indicate that /u/foo is available on server bar. This file system is then mounted locally at /n/bar/u/foo and /u/foo is made a symbolic link to /n/bar/u/foo. (Placing the server name in the name of the mount point is purely a configuration decision, and is not essential.)
Our work is not dependent on Amd; we use it for convenience. Amd typically controls the (un)mounting of all file systems on the client machines on which it runs, and there is no advantage to our work in circumventing it and performing our own (un)mounts.
Amd does not already possess the capabilities we need, nor is our work a simple extension to Amd. Our work adds at least three major capabilities:
Many systems provide a tool, like nfsstat, that returns timing information gathered by the kernel. However, nfsstat is inadequate because it is not as accurate as our measurements, and provides weighted average response time rather than measured response time. Our method additionally is less sensitive to outliers measures both short-term and long-term performance.