Handout 19
NFS*
The Network File System (NFS) is a distributed file system that provides transparent access to remote disks. Instead
of duplicating common directories such as /usr/local on every system, NFS could provide a single copy of the directory
that is shared by all systems on the network. To a host running NFS, remote filesystems are indistinguishable from
local ones. For the user, NFS means that he or she doesn't have to log into other systems to access files. Once
NFS has been set up properly, users should be able to do all their work on their local system; remote files (data
and executables) will appear to be "local" to their own system.
NFS is also built on the RPC (remote procedure call) protocol and imposes a client-server relationship on the hosts
that use it. An NFS server is a host that owns one or more filesystems and makes them available on the network;
NFS clients mount filesystems from one or more servers. This follows the norrnal clientserver model where the server
owns a resource that is used by the client. In the case of NFS, the resource is a physical disk drive that is shared
by all clients of the server.
There are two aspects to system administration using NFS: choosing a filesystem naming and mounting scheme, and
then configuring the servers and clients to adhere to this scheme. The goal of any naming scheme should be to use
network transparency wisely. Being able to mount filesystems from any server is useful only if the files are presented
in a manner that is consistent with what the users' expectations are.
If NFS has been set up correctly, it should be transparent to the user. For example, if locally developed applications
were found in /usr/locaVbin before NFS was installed, they should continue to be found there when NFS is running,
whether /usr/local/bin is on a local filesystem or a remote one. To the user, the actual disk holding /usr/local/bin
isn't important as long as the executables are accessible and built for the right machine architecture. If users
must change their environ ments to locate files accessed through NFS, they will probably dislike the new network
architecture because it changes the way things work.
Setting up NFS on clients and servers involves starting the daemons that handle the NFS RPC protocol, starting
additional daemons for auxiliary services such as file locking, and then simply exporting filesystems from the
NFS servers and mounting them on the clients.
System Administration Using the Network Filesystem
On an NFS client, you need to have the biod, rpc.lockd, and rpc.statd daemons running in order
to use NFS.
The biod daemons perform block 110 operations for NFS clients, performing some simple read-ahead and write-behind
performance optimization. You run multiple instances of biod so that each client process can have multiple NFS
requests out standing at any time.
The rpc.lockd and rpc.statd daemons handle file locking and lock recovery on the client. These locking
daemons also run on an NFS server, and the client-side daemons coordinate file locking on the NFS server through
their serverside counterparts.
* portions from NFS and NIS, Hal Stern, O'Reilly.