On this page
|
| SUMMARY | |
| Protocol |
: |
Network File System |
| Protocol suite |
: |
TCP/IP |
| Layer |
: |
Application Layer |
| Type |
: |
File transfer protocol |
| Latest Version |
: |
NFSv4 |
| Ports |
: |
2049 |
| Working groups |
: |
NFSv4, Network File System Version 4 |
|
| DESCRIPTION |
The NFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This independence is achieved through the use of Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR).
The Network File System (NFS), developed by Sun Microsystems in the 1980's as a way to create a file system on diskless clients. NFS provides remote access to shared file systems across networks. This means that a file system may actually be sitting on machine A, but machine B can mount that filesystem and it will look to the users on machine B like the file system resides on the local machine. In this way NFS is transparent to the user. NFS was also designed to be machine, operating system, network architecture, and transport protocol independent.
NFS is a stateless protocol. This means that the file server stores no per-client information, and there are no NFS "connections". For example, NFS has no operation to open a file, since this would require the server to store state information (that a file is open; what its file descriptor is; the next byte to read; etc). Instead, NFS supports a Lookup procedure, which converts a filename into a file handle. This file handle is a unique, immutable identifier, usually an i-node number, or disk block address. NFS does have a Read procedure, but the client must specify a file handle and starting offset for every call to Read. Two identical calls to Read will yield the exact same results. If the client wants to read further in the file, it must call Read with a larger offset.
The primary functions of NFS are to export or mount directories to other machines, either on or off a local network. These diretories can then be accessed as though they were local. NFS uses a client/server architecture and consists of a client program, a server program, and a protocol used to communicate between the two.
The server program makes filesystems available for access by other machines via a process called exporting. File systems that are available for access across the network are often referred to as shared file systems.
NFS clients access shared file systems mounting them from an NFS server machine. When a file system is mounted, it is integrated into the directory tree. An advanced form of this service is the automounter, which autmomatically mounts and unmounts file systems.
When someone accesses a file over NFS, the kernel places an RPC call to nfsd (the NFS daemon) on the server machine. This call takes the file handle, the name of the file to be accessed, and the user's user and group id as parameters. These are used in determining access rights to the specified file. In order to prevent unauthorized users from reading or modifying files, user and group ids must be the same on both hosts.
On most implementations, the NFS functionality of both client and server are implemented as kernel-level daemons that are started from user space at system boot. These are the NFS daemon (nfsd) on the server host, and the Block I/O Daemon (biod) running on the client host. To improve throughput, biod performs asynchronous I/O using read-ahead and write-behind; also, several nfsd daemons are usually run concurrently.
The NFS implementation of is a little different in that the client code is tightly integrated in the virtual file system (VFS) layer of the kernel and doesn't require additional control through biod. On the other hand, the server code runs entirely in user space, so that running several copies of the server at the same time is almost impossible because of the synchronization issues this would involve. There are currently three versions of NFS. NFS2, NFS3 and NFSv4.
The most important design principles:
- Transparent Access
Users and applications can access remote files as if they were local. They are not required to know whether the files reside on the local disk or on remote servers.
- Statelessness
NFS operates in a stateless manner using remote procedure calls (RPC) built on top of an external data representation (XDR) protocol. The RPC protocol enables version and authentication parameters to be exchanged for security over the network.
When an NFS client mounts file system the server examines the mount request to be sure that the client is authorized, then issues a magic cookie to the client for use in later accesses. The magic cookie keeps the server stateless since no record of authenticated clients needs to be kept. Unmounting and remounting an NFS filesystem changes its magic cookie. Magic cookie persist across reboots provided that you do not boot single user or play with the file systems.
Once the client has the magic cookie it uses RPC to make file requests. Because the server is stateless, it is the responsibility of the client to ensure that it has recieved acknowledgements of write requests before deleting its copy of data.
- Portability
NFS is machine and operating system independent. This allows it to be ported easily to multiple OS and hardware platforms from PCs to mainframes.
- Fast Recovery From Failure
NFS is designed to recover quickly from system failures and network problems, causing minimal disruption of service to users.
- Network Protocol Independence
NFS has the flexibility to run on multiple transport protocols instead of being restricted to just one. This allows it to utilize existing protocols today as well as new protocols in the future.
- Performance
NFS is designed for high performance so that users can access remote files as quickly as they can access local files.
- Security
The NFS architecture enables the utilization of multiple security mechanisms. This allows system administrators to choose the security mechanism that is appropriate for their distributed file sharing environment instead of being restricted to one solution. This also allows NFS to utilize new security mechanisms in the future.
NFS version 4
A distributed filesystem protocol which owes heritage to NFS protocol versions 2 and 3. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added.
The goals of the NFS version 4 revision are as follows:
- Improve access and good performance on the Internet.
- Strong security with negotiation built into the protocol.
- Good cross-platform interoperability.
- Designed for protocol extensions.
The general file system model used for the NFS version4 protocol is the same as previous versions. The server file system is hierarchical with the regular files contained within being treated as opaque byte streams. In a slight departure, file and directory names are encoded with UTF-8 to deal with the basics of internationalization.
A separate protocol to provide for the initial mapping between path name and filehandle is no longer required. Instead of using the older MOUNT protocol for this mapping, the server provides a ROOT filehandle that represents the logical root or top of the file system tree provided by the server.
NFSv4 protocol header
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Octets | | Tag Length | 1-4 | | Tag (depends on Tag length) | 5-N | | Minor Version | N+1-N+4 | | Operation Argument | N+5-N+8 |
- Tag Length
The length in bytes of the tag.
- Tag
Defined by the implementor.
- Minor Version
Each minor version number will correspond to an RFC . Minor version zero corresponds to NFSv4.
- Operation Argument
Operation to be executed by the protocol.
- Operation Argument Values
The operation arg value can be one of the following:
Value | Name | 3 | ACCESS | 4 | CLOSE | 5 | COMMIT | 6 | CREATE | 7 | DELEGPURGE | 8 | DELEGRETURN | 9 | GETATTR | 10 | GETFH | 11 | LINK | 12 | LOCK | 13 | LOCKT | 14 | LOCKU | 15 | LOOKUP | 16 | LOOKUPP | 17 | NVERIFY | 18 | OPEN | 19 | OPENATTR | 20 | OPEN_CONFIRM | 21 | OPEN_DOWNGRADE | 22 | PUTFH | 23 | PUTPUBFH | 24 | PUTROOTFH | 25 | READ | 26 | READDIR | 27 | READLINK | 28 | REMOVE | 29 | RENAME | 30 | RENEW | 31 | RESTOREFH | 32 | SAVEFH | 33 | SECINFO | 34 | SETATTR | 35 | SETCLIENTID | 36 | SETCLIENTID_CONFIRM | 37 | VERIFY | 38 | WRITE |
|
Top of Page
|
| EXAMPLES |
Example 1
The syntax of the NFS URL is a subset of the Generic URL syntax described in RFC 1738.
An NFS URL does not include user or password components, nor does it recognize "?"
query or "#" fragment components.
nfsURL = "nfs" ":" relativeURL
relativeURL = net_path | abs_path | rel_path
net_path = "//" hostport [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path_segments ]
hostport = host [ ":" port ]
host = hostname | hostnumber
hostname = *( domainlabel "." ) toplabel
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
hostnumber = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
url-path = [ "/" ] path_segments
path_segments = segment *( "/" segment )
segment = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
unreserved = alpha | digit | mark
mark = "$" | "-" | "_" | "." | "!" | "~" |
"*" | "'" | "(" | ")" | ","
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9" Example 2
If the server aited to flush data from remote requests, the client would have to save
those requests so that it could resend them in case of a server crash.
/*
* Remote file service routines
*/
program NFS_PROGRAM {
version NFS_VERSION {
void
NFSPROC_NULL(void) = 0;
attrstat
NFSPROC_GETATTR(fhandle) = 1;
attrstat
NFSPROC_SETATTR(sattrargs) = 2;
void
NFSPROC_ROOT(void) = 3;
diropres
NFSPROC_LOOKUP(diropargs) = 4;
readlinkres
NFSPROC_READLINK(fhandle) = 5;
readres
NFSPROC_READ(readargs) = 6;
void
NFSPROC_WRITECACHE(void) = 7;
attrstat
NFSPROC_WRITE(writeargs) = 8;
diropres
NFSPROC_CREATE(createargs) = 9;
stat
NFSPROC_REMOVE(diropargs) = 10;
stat
NFSPROC_RENAME(renameargs) = 11;
stat
NFSPROC_LINK(linkargs) = 12;
stat
NFSPROC_SYMLINK(symlinkargs) = 13;
diropres
NFSPROC_MKDIR(createargs) = 14;
stat
NFSPROC_RMDIR(diropargs) = 15;
readdirres
NFSPROC_READDIR(readdirargs) = 16;
statfsres
NFSPROC_STATFS(fhandle) = 17;
} = 2;
} = 100003; Example 3
These are the sizes, given in decimal bytes, of various XDR structures used in the
protocol
/*
* The maximum number of bytes of data in a READ or WRITE
* request.
*/
const MAXDATA = 8192;
/* The maximum number of bytes in a pathname argument. */
const MAXPATHLEN = 1024;
/* The maximum number of bytes in a file name argument. */
const MAXNAMLEN = 255;
/* The size in bytes of the opaque "cookie" passed by READDIR. */
const COOKIESIZE = 4;
/* The size in bytes of the opaque file handle. */
const FHSIZE = 32; |
Top of Page
|
| PROTOCOL RELATIONS |
■ Parent layer
■ Child layer
TCP/UDP
|  | NFS | |
Top of Page
|
| GLOSSARY |
|
GSS-API The GSS-API (Generic Security Service Application Program Interface) is a generic API for doing client-server authentication.
A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies.
The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), from the operations of providing per-message data origin authentication and data integrity protection (GSS_GetMIC() and GSS_VerifyMIC() calls) for messages subsequently transferred in conjunction with that context.
Gopher A system that pre-dates the World Wide Web for organizing and displaying files on Internet servers. A Gopher server presents its contents as a hierarchically structured list of files. With the ascendance of the Web, many gopher databases were converted to Web sites which can be more easily accessed via Web search engines.
Gopher was developed at the University of Minnesota and named after the school's mascot. Two systems, Veronica and Jughead, let you search global indices of resources stored in Gopher systems.
IETF IETF (Internet Engineering Task Force) is the main standards organization for the Internet. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.
WAIS WAIS (Wide Area Information Server) is an Internet system in which specialized subject databases are created at multiple server locations, kept track of by a directory of servers at one location, and made accessible for searching by users with WAIS client programs. The user of WAIS is provided with or obtains a list of distributed databases. The user enters a search argument for a selected database and the client then accesses all the servers on which the database is distributed. The results provide a description of each text that meets the search requirements. The user can then retrieve the full text.
|
Top of Page
|
| REFERENCES |
RFCs:
[ RFC 2224] NFS URL Scheme.
Defines NFS URL nfs:.
[ RFC 2339] An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols.
[ RFC 2623] NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5.
[ RFC 2624] NFS Version 4 Design Considerations.
[ RFC 3530] Network File System (NFS) version 4 Protocol.
Defines NFS version 4.
Obsoletes: RFC 3010. Obsolete RFCs:
[ RFC 1094] NFS: Network File System Protocol Specification.
Obsoleted by: RFC 3010.
Defines NFS version 2.
[ RFC 1813] NFS Version 3 Protocol Specification.
Obsoleted by: RFC 3010.
Defines NFS version 3.
[ RFC 3010] NFS version 4 Protocol.
Obsoleted by: RFC 3530.
Defines NFS version 4.
Obsoletes: RFC 1094, RFC 1813. Publications
[ISBN 1565925106] Managing NFS and NIS, 2nd Edition.
[ISBN 0201325705] NFS Illustrated
|
Top of Page
|
| OTHER PROTOCOLS OF TCP/IP SUITE |
|
|
|
|
|