Chapter 6. System Administration Using the Network File System

The Network File System (NFS) is a distributed filesystem that provides transparent access to remote disks. Just as NIS allows you to centralize administration of user and host information, NFS allows you to centralize administration of disks. Instead of duplicating common directories such as /usr/local on every system, NFS provides 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. There is no need to use rcp or tapes to move files onto the local system. 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 and NIS are frequently used together: NIS makes sure that configuration information is propagated to all hosts, and NFS ensures that the files a user needs are accessible from these hosts.

NFS is also built on the RPC 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 normal client-server 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 the users' expectations.

If NFS has been set up correctly, it should be transparent to the user. For example, if locally developed applications were found in /usr/local/bin 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 environments to locate files accessed through NFS, they will probably dislike the new network architecture because it changes the way things work.

An environment with many NFS servers and hundreds of clients can quickly become overwhelming in terms of management complexity. Successful system administration of a large NFS network requires adding some intelligence to the standard procedures. The cost of consistency on the network should not be a large administrative overhead. One tool that greatly eases the task of running an NFS network is the automounter, which applies NIS management to NFS configuration. This chapter starts with a quick look at how to get NFS up and running on clients and servers, and then explores NFS naming schemes and common filesystem planning problems. We'll cover the automounter in detail in Chapter 9, "The Automounter".

6.1. Setting up NFS

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.

On an NFS client, you need to have the lockd and statd daemons running in order to use NFS. These daemons are generally started in a boot script (Solaris uses /etc/init.d/nfs.client):

if [ -x /usr/lib/nfs/statd -a -x /usr/lib/nfs/lockd ]
then
	/usr/lib/nfs/statd > /dev/console 2>&1
	/usr/lib/nfs/lockd > /dev/console 2>&1
fi

On some non-Solaris systems, there may also be biod daemons that get started. The biod daemons perform block I/O operations for NFS clients, performing some simple read-ahead and write-behind performance optimizations. You run multiple instances of biod so that each client process can have multiple NFS requests outstanding at any time. Check your vendor's documentation for the proper invocation of the biod daemons. Solaris does not have biod daemons because the read-ahead and write-behind function is handled by a tunable number of asynchronous I/O threads that reside in the system kernel.

The lockd and 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 server-side counterparts. We'll come back to file locking later when we discuss how NFS handles state information.

On an NFS server, NFS services are started with the nfsd and mountd daemons, as well as the file locking daemons used on the client. You should see the NFS server daemons started in a boot script (Solaris uses /etc/init.d/nfs.server):

if grep -s nfs /etc/dfs/sharetab >/dev/null ; then
	/usr/lib/nfs/mountd
	/usr/lib/nfs/nfsd -a 16
fi

On most NFS servers, there is a file that contains the list of filesystems the server will allow clients to mount via NFS. Many servers store this list in /etc/exports file. Solaris stores the list in /etc/dfs/dfstab. In the previous script file excerpt, the NFS server daemons are not started unless the host shares (exports) NFS filesystems in the /etc/dfs/dfstab file. (The reference to /etc/dfs/sharetab in the script excerpt is not a misprint; see Section 6.2, "Exporting filesystems".) If there are filesystems to be made available for NFS service, the machine initializes the export list and starts the NFS daemons. As with the client-side, check your vendor's documentation or the boot scripts themselves for details on how the various server daemons are started.

The nfsd daemon accepts NFS RPC requests and executes them on the server. Some servers run multiple copies of the daemon so that they can handle several RPC requests at once. In Solaris, a single copy of the daemon is run, but multiple threads run in the kernel to provide parallel NFS service. Varying the number of daemons or threads on a server is a performance tuning issue that we will discuss in Chapter 17, "Network Performance Analysis". By default, nfsd listens over both the TCP and UDP transport protocols. There are several options to modify this behavior and also to tune the TCP connection management. These options will be discussed in Chapter 17, "Network Performance Analysis" as well.

The mountd daemon handles client mount requests. The mount protocol is not part of NFS. The mount protocol is used by an NFS server to tell a client what filesystems are available (exported) for mounting. The NFS client uses the mount protocol to get a filehandle for the exported filehandle.


5.6. What next?		6.2. Exporting filesystems

Chapter 6. System Administration Using the Network File System

Contents:

6.1. Setting up NFS