Exploring NFS in UNIX

If your computer is on a LAN, the computer is probably set up to share files with other computers. Quite a few different schemes enable computers to use files on other machines. These schemes are named mostly with TLAs (Three Letter Acronyms) such as AFS, RFS, and NFS. Here, you find out about NFS (you'll never find your stuff) because that's the most commonly used scheme, even though it works, in many ways, the worst.

What's NFS?

The NFS (Network File System) program enables you to treat files on another computer in more or less the same way you treat files on your own computer.

You may want to use NFS for several reasons:

• Often you have a bunch of similar computers scattered around, all running more or less the same programs. Rather than load every program on every computer, the system administrator loads one copy of everything on one computer (the server) so that all the other computers (the clients) can share the programs.

• Centralizing the files on a server makes backup and administration easier. It's much easier to administer one disk of 4,000 megabytes than to administer 10 disks of 400 megabytes apiece. It's also easier to back up everything because everything is all in one place rather than spread around on a dozen machines.

• Another use of NFS is to make a bunch of workstations function as a shared time-sharing system. It is reasonably straightforward to set up a bunch of workstations so that you can sit down at any one of them, log in, and use the same set of files regardless of where on the network they physically reside. This capability is a great convenience. Also, by using programs such as ssh, you can log in to another machine on the network and work from that machine (which is handy if the other machine is faster than yours or has some special feature you want to use).

• In heterogeneous networks, NFS is a fancy term for networks with different kinds of computers. NFS is available for all sorts of computers, from PCs to mainframes.

Ignoring NFS

Except when NFS screws up, you don't have to worry about using it. Your system administrator did all the hard work when she installed it.

Files passed over the network act almost exactly like those on the local machine; in most cases, you can treat them the same. The primary difference is that access to files through NFS is about twice as slow as access to files on the local machine. This problem usually isn't a big one because, for most of the stuff you do, the machine doesn't spend much time waiting for the disk anyway.

Wnen you do something really big and slow (such as repaginate a 500-page document), seeing whether you can log in to the machine on which the files reside and run the program there may be worth the time.

Where are those files, anyway?

NFS works by mounting remote directories. Mounting means pretending that a directory on another disk or even on another computer is actually part of the directory system on your disk. Files that are stored in lots of different places can then appear to be nicely organized into one tree-structure directory.

Whenever UNIX sees the name of a directory — /stars/elvis, for example — it checks to see whether any names in the directory are mount points, which are directories in which one disk is logically attached to another.

Your system may have the directory /stars mounted from some other machine, for example, and then the directory elvis and all the files in it reside on the other machine.

The easiest way to tell which files are where is with the df (Disk Free space) command. It prints the amount of free space on every disk and tells you where the disks are. Here's a typical piece of df output:

Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 30383 6587 20758 24% /
/dev/sd0g 157658 124254 17639 88% /usr
/dev/sd0h 364378 261795 66146 80% /home
/dev/sd3a 15671 1030 13074 7% /tmp
/dev/sd3g 1175742 758508 299660 72% /mnt
server-sys:/usr/spool/mail
300481 190865 79567 71% /var/spool/mail
server-sys:/usr/lib/news
300481 190865 79567 71% /usr/lib/news
server-sys:/usr/spool/news
298068 243877 24384 91% /var/spool/news

In this example, the directory / resides on a local disk (a disk on your own computer) named /dev/sd0a; /usr resides on /dev/sd0g; /home resides on /dev/sd0h; and so on. The directory /var/spool/mail is really the directory /usr/spool/mail on machine server-sys, /usr/lib/news is really /usr/lib/news on machine server-sys, and so on.

Some of the local directory names are the same as the remote machine's directory names — and some aren't. This situation can and often does cause considerable confusion; unfortunately, it's usually unavoidable. A system administrator with any sense at least mounts each directory with a consistent name wherever it's mounted so that /var/documents/bigproject is the same no matter which computer you're working on.

A database known as NIS (Network Information System) makes keeping straight the naming process easier. Don't worry about it unless your system administrator messes up.

NFS and system crashes

What happens if you're working with NFS, your files are stored on a server, and the server crashes? The answer is, you wait. Eventually, when the server comes back, you continue from where you left off. If the crash is severe, you may wait a long time.

The worst practical problem is that, if a program stalls while it is waiting for a dead NFS server, you have no way to stop or kill the program, short of rebooting your UNIX computer.

Recent versions of NFS have features called soft and hard mounts that make stopping a program that has stalled while waiting for a dead server possible. The problem is that, if a server is merely slow and not dead, a client may assume that the server is dead and stop a program. Had the client been a little more patient, the server would have responded, and the program could have completed its task.