NFS Operation Overview

Linux data storage disks contain files stored in filesystems with a standardized directory structure. New disks are added by attaching, or mounting, the directories of their filesystems to a directory of an already existing filesystem. This in effect makes the new hard disk transparently appear to be a subdirectory of the filesystem to which it is attached.

NFS was developed to allow a computer system to access directories on remote computers by mounting them on a local filesystem as if they were a local disk. The systems administrator on the NFS server has to define the directories that need to be activated, or exported, for access by the NFS clients, and administrators on the clients need to define both the NFS server and the subset of its exported directories to use.

General NFS Rules

You should follow some general rules when configuring NFS:

• Only export directories beneath the / directory.

• Do not export a subdirectory of a directory that has already been exportedthe exception being when the subdirectory is on a different physical device. Likewise, do not export the parent of a subdirectory unless it is on a separate device.

• Only export local filesystems.

Keep in mind that when you mount any filesystem on a directory, the original contents of the directory are ignored, or obscured, in favor of the files in the mounted filesystem. When the filesystem is unmounted, then the original files in the directory reappear unchanged.

Key NFS Concepts

Data access over a network always introduces a variety of challenges, especially if the operation is intended to be transparent to the user, as in the case of NFS. Here are some key NFS background concepts that will help in your overall understanding.

VFS

The virtual filesystem (VFS) interface is the mechanism used by NFS to transparently and automatically redirect all access to NFS-mounted files to the remote server. This is done in such a way that files on the remote NFS server appear to the user to be no different than those on a local disk.

VFS also translates these requests to match the actual filesystem format on the NFS server's disks. This allows the NFS server to be not only a completely different operating system, but also use different naming schemes for files with different file attribute types.

Stateless Operation

Programs that read and write to files on a local filesystem rely on the operating system to track their access location within the file with a pointer. As NFS is a network-based file system, and networks can be unreliable, it was decided that the NFS client daemon would act as a failsafe intermediary between regular programs running on the NFS client and the NFS server.

Normally, when a server fails, file accesses timeout and the file pointers are reset to zero. With NFS, the NFS server doesn't maintain the file pointer information, the NFS client does. This means that if an NFS server suddenly fails, the NFS client can precisely restart the file access once more after patiently waiting until the server returns online.

Caching

NFS clients typically request more data than they need and cache the results in memory locally so that further sequential access of the data can be done locally versus over the network. This is also known as a read ahead cache. Data that's to be written to the NFS server is cached with the data being written to the server when the cache becomes full. Caching therefore helps to reduce the amount of network traffic while simultaneously improving the speed of some types of data access.

The NFS server caches information too, such as the directory information for the most recently accessed files and a read ahead cache for recently read files.

NFS and Symbolic Links

You have to be careful with the use of symbolic links on exported NFS directories. If an absolute link points to a directory on the NFS server that hasn't been exported, then the NFS client won't be able to access it.

Unlike absolute links, relative symbolic links are interpreted relative to the client's filesystem. Consider an example where the /data1 directory on the server is mounted on the /data1 directory. If there is a link to the ../data2 directory on the NFS server and a directory corresponding to ../data2 doesn't exist on the NFS client, then an error will occur.

Also, mounting a filesystem on a symbolic link actually mounts the filesystem on the target of the symbolic link. You'll have to be careful not to obscure the contents of this original directory in the process. Plan carefully before doing this.

NFS Background Mounting

NFS clients use the remote procedure call (RPC) suite of network application helper programs to mount remote filesystems. If the mount cannot occur during the default RPC timeout period, then the client retries the mount process until the NFS number of retries has been exceeded. The default is 10,000 minutes, which is approximately a week. The difficulty here is that if the NFS server is unavailable, the mount command will hang for a week until it returns online. It is possible to use a bg option to spawn the retries off as a subprocess so that the main mount command can continue to process other requests.

Hard and Soft Mounts

The process of continuous retrying, whether in the background or foreground, is called a hard mount. NFS attempts to guarantee the consistency of your data with these constant retries. With soft mounts, repeated RPC failures cause the NFS operation to fail not hang and data consistency is therefore not guaranteed. The advantage is that the operation completes quickly, whether it fails or not. The disadvantage is that the use of the soft option implies that you are using an unreliable NFS server; if this is the case it is best not to place critical data that needs to be updated regularly or executable programs in such a location.

NFS Versions

Three versions of NFS are available currently: versions 2, 3, and 4. Version 1 was a prototype. This chapter focuses on version 2, which:

• Supports files up to 4GB long

• Requires an NFS server to successfully write data to its disks before the write request is considered successful

• Has a limit of 8KB per read or write request

The main differences with version 3 are that it:

• Supports extremely large file sizes of up to 264 - 1 bytes

• Supports the NFS server data updates as being successful when the data is written to the server's cache

• Negotiates the data limit per read or write request between the client and server to a mutually decided optimal value

Version 4 maintains many of version 3's features, but with the additions that:

• File locking and mounting are integrated in the NFS daemon and operate on a single, well known TCP port, making network security easier

• File locking is mandatory, whereas before it was optional

• Support for the bundling of requests from each client provides more efficient processing by the NFS server

It is important to match the versions of NFS running on clients and servers to help ensure the necessary compatibility to get NFS to work predictably.

Important NFS Daemons

NFS isn't a single program, but a suite of interrelated programs that work together to get the job done:

• portmap: The primary daemon upon which all the others rely, portmap manages connections for applications that use the RPC specification. By default, portmap listens to TCP port 111 on which an initial connection is made. This is then used to negotiate a range of TCP ports, usually above port 1024, to be used for subsequent data transfers. You need to run portmap on both the NFS server and client.

• nfs: Starts the RPC processes needed to serve shared NFS file systems. The nfs daemon needs to be run on the NFS server only.

• nfslock: Used to allow NFS clients to lock files on the server via RPC processes. The nfslock daemon needs to be run on both the NFS server and client.

• netfs: Allows RPC processes run on NFS clients to mount NFS filesystems on the server. The nfslock daemon needs to be run on the NFS client only.

Now take a look at how to configure these daemons to create functional NFS client/server peering.