Network File System (NFS), originally developed by Sun Microsystems and then extended by IETF, allows file sharing over network among different types of systems. In other words, NFS was designed for remote file access and sharing over network with various types of machines, operating systems, network architecture and transport protocols.
NFS uses a client/server architecture and consists of a client program and a server program. The server program makes file systems available for access by other machines via a process called exporting . NFS clients access shared file systems mounting them from an NFS server machine. NFS mount protocol is used to communicate between the server and the client for the file access and sharing. NFS mount protocol also allows the server to grant remote access privileges to a restricted set of clients via export control.
NFS Version 2, the first widely implemented version of NFS, originally operated entirely over UDP and was meant to keep the protocol stateless. Several vendors had extended NFSv2 to support TCP as transport. NFS Version 3 introduced support for using TCP as transport. Using TCP as transport made using NFS over a WAN more feasible . Inheritated the good features of the previous versions, the current NFS Version 4 features the following improvements:
- Improved access and performance on the Internet. The protocol is designed to transit firewalls easily, perform well where latency is high and bandwidth is low, and scale to very large numbers of clients per server.
- Strong security with negotiation built into the protocol. The protocol builds on the work of the ONCRPC working group in supporting the Remote Prcedure Call (RPC) RPCSEC_GSS protocol. Additionally, the NFS version 4 provides a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes.
- Designed for protocol extensions. The protocol is designed to accept standard extensions that do not compromise backward compatibility.
NFS is strongly associated with UNIX systems, though it can be used on any platform such as Macintosh and Microsoft Windows operating systems. The Server Message Block (SMB) and Common Internet File System (CIFS) are a similar protocol that have equivalent implementation of a network file system under Microsoft Windows.
Protocol Structure
NFS protocol support many basic data types of files. In addition NFS protocol supports the following structured data types:
| Name | Structure | Notes |
| nfstime4 | struct nfstime4 { int64_t seconds; uint32_t nseconds; } |
The nfstime4 structure gives the number of seconds and nanoseconds since 0 hour January 1, 1970 Coordinated Universal Time (UTC). This data type is used to pass time and date information. |
| time_how4 | enum time_how4 { SET_TO_SERVER_TIME4 = 0, SET_TO_CLIENT_TIME4 = 1 }; |
It is used as the attribute definitions to set time values. |
| settime4 | union settime4 switch { case SET_TO_CLIENT_TIME4: nfstime4 time; default: void; }; |
It is used as the attribute definitions to set time values. |
| specdata4 | struct specdata4 { uint32_t specdata1; uint32_t specdata2; }; |
This data type represents additional information for the device file types NF4CHR and NF4BLK. |
| fsid4 | struct fsid4 { uint64_t major; uint64_t minor; }; |
This type is the filesystem identifier that is used as a mandatory attribute. |
| fs_location4 | struct fs_location4 { utf8str_cis server<>; pathname4 rootpath; }; |
It is used for the fs_locations recommended attribute which is used for migration and replication support. |
| fs_locations4 | struct fs_locations4 { pathname4 fs_root; fs_location4 locations<>; }; |
It is used for the fs_locations recommended attribute which is used for migration and replication support. |
| fattr4 | struct fattr4 { bitmap4 attrmask; attrlist4 attr_vals; }; |
The fattr4 structure is used to represent file and directory attributes. |
| change_info4 | struct change_info4 { bool atomic; changeid4 before; changeid4 after; }; |
This structure is used with the CREATE, LINK, REMOVE, RENAME operations to let the client know the value of the change attribute for the directory in which the target filesystem object resides. |
| clientaddr4 | struct clientaddr4 { string r_netid<>; string r_addr<>; }; |
It is used as part of the SETCLIENTID operation to either specify the address of the client that is using a clientid or as part of the callback registration. |
| cb_client4 | struct cb_client4 { unsigned int cb_program; clientaddr4 cb_location; }; |
This structure is used by the client to inform the server of its call back address; includes the program number and client address. |
| nfs_client_id4 | struct nfs_client_id4 { verifier4 verifier; opaque id <NFS4_OPAQUE_LIMIT>; }; |
This structure is part of the arguments to the SETCLIENTID operation. |
| open_owner4 | Struct open_owner4 { clientid4 clientid; opaque wner <NFS4_OPAQUE_LIMIT>; }; |
This structure is used to identify the owner of open state. |
| lock_owner4 | struct lock_owner4 { clientid4 clientid; opaque owner <NFS4_OPAQUE_LIMIT>; }; |
This structure is used to identify the owner of file locking state. |
| open_to_lock_owner4 | struct open_to_lock_owner4 { seqid4 open_seqid; stateid4 open_stateid; seqid4 lock_seqid; lock_owner4 lock_owner; }; |
This structure is used for the first LOCK operation done for an open_owner4. It provides both the open_stateid and lock_owner such that the transition is made from a valid open_stateid sequence to that of the new lock_stateid sequence. |
| stateid4 | struct stateid4 { uint32_t seqid; opaque other[12]; }; |
This structure is used for the various state sharing mechanism between the client and server. |
Related protocols: SMB, CIFS, RPC, TCP, UDP
Sponsor Source: NFS was originally created by Sun Microsystems and now is an IETF protocol.
Reference:
http://www.javvin.com/protocol/rfc3530.pdf : NFS Version 4 Protocol Specification
http://www.javvin.com/protocol/rfc1813.pdf : NFS Version 3 Protocol Specification
http://www.javvin.com/protocol/rfc1094.pdf : NFS Version 2 Protocol Specification