• Choose a category
• All
• Classic-Fiction

By Root 454 0

on which they will be performed. Filehandles are created on the server and contain information that uniquely identifies the file or directory on the server. The client's NFS mount and lookup requests retrieve these filehandles for existing files. A side effect of making all vnodes homogeneous is that file pathname lookup must be done one component at a time. Each directory in the pathname might be a mount point for another filesystem, so each name look-up request cannot include multiple components. For example, let's look at Client A that NFS-mounts the /usr/local filesystem and also NFS-mounts a filesystem on /usr/local/bin:

clientA# mount server1:/usr/local /usr/local

clientA# mount server2:/usr/local/bin.mips /usr/local/bin

When the NFS client reaches the bin component in the pathname, it realizes that there is an NFS filesystem mounted on this directory, and it sends its lookup requests to server2 instead of server1. If the NFS client passed the whole pathname to server1, it might get the wrong answer on its lookup: server1 has its own /usr/local/bin directory that may or may not be the same directory that Client A has mounted. While this may seem to be a very expensive series of operations, the kernel keeps a directory name lookup cache (DNLC) that prevents every look-up request from going to an NFS server.

The lookup operation takes a filename and a filehandle for a directory, and returns a filehandle pointing to the named file on the server. How then does the pathname traversal get started, if every lookup requires a filehandle from a previous pathname resolution? The mount operation seeds the lookup process by providing a filehandle for the root of the mounted filesystem. Within NFS, the only procedure that accepts full pathnames is the mount RPC, which turns the pathname into a filehandle for the mounted filesystem.

Let's look at how NFS turns the pathname /usr/local/bin/emacs into an NFS filehandle, assuming that it's on a filesystem mounted on /usr/local from server wahoo:

The NFS client asks the mountd daemon on wahoo for a filehandle for the filesystem the client has mounted on /usr/local, using the server's pathname that was supplied in the /etc/vfstab file or mount command. That is, if the client has mounted /usr/local with the /etc/vfstab entry:wahoo:/tools/local - /usr/local nfs - yes ro,hard

then the client will ask wahoo for a filehandle for the /tools/local directory.[2]

Using the mount point filehandle, the client performs a lookup operation on the next component in the pathname: bin. It sends a lookup to wahoo, supplying the filehandle for the /usr/local directory and the name "bin." Server wahoo returns another filehandle for this directory.

The client goes to work on the next component in the path, emacs. Again, it sends a lookup using the filehandle for the directory containing emacs and the name it is looking for. The filehandle returned by the server is used by the client as a "pointer" (on the server) to /usr/local/bin/emacs (in the filesystem seen by client) for all future operations on that file.

Filehandles are opaque to the client. In most NFS implementations on Unix machines, they are an encoding of the file's inode number, disk device number, and inode generation number. Other implementations, particularly non-Unix NFS servers that do not have inodes, encode their own native filesystem information in the filehandle. In any system, the filehandle is in a form that can be disassembled only on the NFS server. The structures contained in the filehandle are kept hidden from the client, the same way the structures in an object-oriented system are hidden in the object's implementation routines. In the case of NFS filehandles, the data described by the structure doesn't even exist on the client — it's all on the server, where the filehandle can be converted into a pointer to local file.

Filehandles become invalid, or stale, when the inodes to which they point (on the server) are freed or re-used. NFS clients have no way of knowing what other operations may be affecting objects pointed