Sidebar: NFS and RFS

Working in conjunction with S5 and UFS, the Network File System first appeared in SunOS in 1984. It has since been placed in public domain and prospered on every platform. Designed to work independently of hardware, it allows sharing files and directories across the network within a heterogeneous environment. Thus, servers running operating systems other than UNIX can have their drives mounted as long as they are using a TCP/IP stack and NFS.

AT&T attempted to provide the same capability with System V Release 3, and came up with RFS (Remote File Sharing). Unlike NFS, RFS required that all machines on the network be running SVR3 or later. As a result, and given the usual mixture of machines on a network, RFS has almost completely faded from view as NFS has been widely accepted.

The underlying component that does all the work for NFS and RFS is the Remote Procedure Call (RPC). Using RPC, an application or program on one machine can summon a process on a remote machine and have the executed results displayed on the local machine. NFS performs these operations, and is transported around the network, using the TCP/IP'S User Datagram Protocol (UDP). By relying upon UDP to do the transportation, NFS becomes a stateless protocol, considering each transaction independently of any that happened before it.

With statelessness, whenever a user requests a file, a copy of that file is placed in a memory cache at the requesting workstation. Any changes made to the file are made within that cache. If another user on the same or another workstation requests the same file, a copy of the original is placed in cache for that person, too. The second user does not know that someone else has the file already open, and the first user does not know that someone else requested it. The first user could make changes, then save and exit, only to find that the changes were overwritten when the second user saved different changes.

Mounting a directory across a network requires two operations. First, the directory must be exported, or marked as shareable across the network. The command for this on a Solaris machine is:

# share -F nfs -o rw=domain.name -d "The Directory" /export/safe/home

In this command, /export/safe/home is the disk being shared. The next step is to mount the directory on the machine that is to see it, using:

# mount -t nfs domain.name:/export/safe/home /mnt -o rw

Once the directory is shared and mounted, users on both systems, except for the root user, can read and write to the drive. The root user, being all powerful on one machine, is restricted from being all powerful on the other machine. Root cannot write to the mounted drive. This is a security measure preventing someone with root access from wreaking havoc across the network.

Beware of named pipes on NFS. Named pipes are special files that store, or block, data until a process comes along and performs some operation on that data -- device special files, you might say. If the named pipe is on machine one, it is often optimized by the kernel as a domain stream. It works well as long as all the operations are local. If machine two NFS-mounts the volume containing the named pipe, problems can occur. Think of the consequences if a process on machine two attempts to read the data blocked at the pipe before it is processed by the designated process on machine one. Corruption and ugliness can occur. For that reason, named pipes do not work over NFS. They do work under RFS, which supports the sharing of device special files across the network.