Network File System

Networked File System

Introduction

The networked file system, known as NFS and defined in RFC 1094 is used to allow hosts to share files across a network. It was first described by Sun Mircosystems Inc in 1989 and has been part of their standard product offerings since that date. It has been widely implemented on other platforms. Version 3 of the protocol defined in RFC 1813 was published in 1995.

The networked file system operates on a client-server basis using network messages to transfer requests and data between clients and servers. Data values are encoded using a method known as XDR (external data representation) described in RFC 1014. Traffic between the client and server uses the remote procedure call mechanism described in RFC 1057. NFS normally uses the UDP protocol and servers listen on port 2049.

Modern Unix hosts use a mechanism known as the virtual file system which identifies files via virtual i-nodes (usually known as v-nodes) which replace the well known i-nodes as far as the file management system is concerned. When accessing a file via a v-node the kernel will use the associated file system pointer to identify the functions that perform various low-level actions on files.

Provided the appropriate drivers are installed several different sorts of file system can be mounted via this mechanism, these include a normal Unix file system, a networked file system, a "High Sierra" file system (on a CDROM) and an MSDOS file system (known as PCFS) on a floppy disc. Such systems are integrated into the Unix virtual file system using the mount command.

Remote Procedure Calls

Remote procedure calls look similar to normal procedure calls, data is passed to a function and a value is returned. The procedure body, however, is really a stub that generates a message that includes a code number identifying the remote procedure and the parameters that are to be passed to the remote procedure. The stub also receives and decodes replies. A remote procedure call will block until a value has been returned by the remote host that does the actual processing.

The RPC message can also include authentication that identifies the process that is ultimately responsible for the request, this would normally include both issuing host identification and uid of the issuing process. Several levels of authentication are available ranging from none at all to DES encoded key exchange for every transaction.

Basic Ideas

NFS adopts a stateless model of transaction processing, this means that, essentially, the server does not maintain any historical information about any of the dialogues it may be running with remote clients. This offers very considerable advantages for restarting dialogues after server or network failure. Basic NFS does not support notions such as file locking, there are separate services for such needs.

NFS identifies file operations as being potentially idempotent which means that they can validly be repeated. This addresses the problems that may arise when an NFS request is duplicated in the course of transmission or is re-sent because an acknowldegment was lost.

Note that the fact that there is no requirement for the server to be stateful, does not mean it cannot be stateful. A server implementation may main state information (e.g. by doing block read aheads) in order to enhance performance.

NFS does not work directly with path names. Each component of a path name has to be handled separately. This avoids complexities with different path name syntaxes on different hosts and also makes it much easier to deal with "mount-on-mount" situations where the server is also a client of yet another server.

The procedures

There are 18 defined procedures supporting NFS. These are described below. All the procedures are synchronous which means that they block or do not return until they have been processed. The response to a request will always include a status code indicating whether the operation has completed successfully or has failed for some reason related to the server file system semantics.

NULL

This does nothing, it may be used for server response and timing tests.

GETATTR

This is used for getting file attributes. It has a single parameter of type fhandle to identify the file. The returned value consists of a status code and a block of information of type fattr which contains all the normal file information. The Unix style semantics will be noted. The fhandle is an arbitrary value delivered by the server to the client in response to a LOOKUP request and uniquely identifying a particular file.

type - the following types are specified, using the following code numbers.

named socket

regular file

directory

block special file

character special file

symbolic link file

mode - access rights using Unix semantics

nlink - hard link count

uid - user identification of owner

gid - group identification of owner

size - file size (in bytes)

blocksize - size (in bytes) of a file block

rdev - device identifier

blocks - number of blocks in file

fsid - file system identifier

fileid - file identifier within file system

atime - time of last access

mtime - time of last modification

ctime - time of last status change

SETATTR

This can be used to modify the file attributes. The file is identified by a parameter of type fhandle and the new values of the following parameters are included in a parameter of type sattr.

mode

uid

gid

size

atime