The Solaris 2.5 through Solaris 7 operating environments are shipped with NFS Version 2 and NFS version 3. NFS version 3 is a new addition to the Solaris operating environments beginning with Solaris 2.5.
The NFS client negotiates with the server regarding whether to use NFS version 2 or NFS version 3. If the server supports NFS version 3, then version 3 becomes the default to use. You can override the default NFS version used with the vers= mount option.
You tune NFS version 2 and NFS version 3 similarly.
NFS version 3 contains several features to improve performance, reduce server load, and reduce network traffic. Since NFS version 3 is faster for I/O writes, and uses fewer operations over the network, you will have more efficient use of the network. Note that higher throughput may make the network busier.
NFS version 3 maintains the stateless server design and simple crash recovery of version 2 along with its approach to build a distributed file service from cooperating protocols.
Table 1-1 describes the NFS operations and their functions for versions 2 and 3. Table 1-2lists the NFS operations new to Version 3.
Table 1-1 NFS Operations in Version 2 and Version 3
Operation |
Function in Version 2 |
Change in Version 3 |
---|---|---|
create |
Creates a file system node; may be a file or a symbolic link |
No change |
statfs |
Gets dynamic file system information |
Replaced by fsstat |
getattr |
Gets file or directory attributes such as file type, size, permissions, and access times |
No change |
link |
Creates a hard link in the remote file system |
No change |
lookup |
Searches directory for file and return file handle |
No change |
mkdir |
Creates a directory |
No change |
null |
Does nothing; used for testing and timing of server response |
No change |
read |
Reads an 8-Kbyte block of data (32-KByte blocks). This can be raised beyond 64 KBytes for TCP. |
Block of data up to 4 Gbytes |
readdir |
Reads a directory entry |
No change |
readlink |
Follows a symbolic link on the server |
No change |
rename |
Changes the directory name entry |
No change |
remove |
Removes a file system node |
No change |
rmdir |
Removes a directory |
No change |
root |
Retrieves the root of the remote file system (not presently used) |
Removed |
setattr |
Changes file or directory attributes |
No change |
symlink |
Makes a symbolic link in a remote file system |
No change |
wrcache |
Writes an 8 Kbyte block of data to the remote cache (not presently used) |
Removed |
write |
Writes an 8 Kbyte block of data (32-KByte blocks). This can be raised beyond 64 KBytes for TCP. |
Block of data up to 4 Gbytes |
Table 1-2 New NFS Operations in Version 3
Operation in Version 3 |
Function |
---|---|
access |
Check access permission |
mknod |
Create a special device |
readdir |
Read from directory |
readdirplus |
Extended read from directory |
fsinfo |
Get static file system information |
pathconf |
Retrieve POSIX information |
commit |
Commit cached data on a server to stable storage |
The root and writecache operations have been removed. A mknod operation has been defined to allow the creation of special files, thus eliminating the overloading of create. Caching on the client is not defined nor dictated by Version 3. Additional information and hints have been added to Version 3 to allow clieints that implement caching to manage their caches more effectively.
Operations that affect the attributes of a file or directory may now return the new attributes after the operation has completed to optimize out a subsequent getattr used in validating attribute caches. Also, operations that modify the directory in which the target object resides return the old and new attribues of the directory to allow clients to implement more intelligent cache invalidation procedures.
The access operation provides access permission checking on the server. The fsstat operation returns static information about a file system and server. The readdirplus operation returns file handles and attributes in additional to directory entries. The pathconf operation returns POSIX pathconf information about a file.
Version 3 of the NFS protocol enables access to files whose length fits in 64 bits. With version 2, the length had to fit in 32 bits (4 Gbytes).
Access to large files (64-bit) is possible only if the client, server, and the operating system support large files. If the client implementation is limited to 32-bit files, then the client can't access files larger than 32 bits (even if the server supports them). Conversely, if the client supports 64-bit files but the server only supports 32-bit files, the client is limited to 32-bit files. The Solaris 7 operating environment is the first Solaris release that takes advantage of this protocol feature. Operating environments prior to Solaris 7 did not have 64-bit file support.
The limit for the UNIX File System in the Solaris 2.6 and 7 operating environments is 1 Terrabyte (40 bits).
NFS version 3 can use asynchronous writes, which is optional. The NFS version 3 client sends asynchronous write requests to the server, which acknowledges receiving the data. However, the server is not required to write the data to stable storage before replying. The server may schedule the write, or wait to gather multiple write requests together.
The client maintains a copy of the data in case the server is unable to complete the writes. When the client wants to free its copy, it notifies the server with a COMMIT operation. The server responds positively only after it ensures that the data is written to stable storage. Otherwise, it responds with an error and the client resends the data synchronously.
Asynchronous writes enable the server to determine the best policy to synchronize the data. The data is most likely synchronized by the time the COMMIT arrives. Compared with NFS version 2, this scheme enables better buffering and more parallelism.
With NFS version 2, the server does not respond to a write request until the data is placed in stable storage. However, it may use techniques such as write gathering to issue multiple concurrent requests before responding to any of the requests.
NFS version 3 contains an operation called READDIRPLUS. Most READDIRs are now issued as READDIRPLUS calls; for example, an ls or an ls -l triggers READDIRPLUS calls. When the ls -l commands run over version 3, the file handles and attributes are returned with the list of names in the directory. In version 2, the names are returned first, then additional calls to the server are required to obtain the file handles and attributes.
The advantage of the READDIRPLUS operation in version 3 is that an ls and an ls -l are now comparable in speed because separate GETATTR requests are not required for each file.
Many NFS version 2 clients cache file and directory data to improve performance. At times, the version 2 method fails when multiple clients are sharing and caching the same data.
Weak cache consistency enables the client to detect data changes between its last access and the current request. This is done when the server sends back the previous attributes with the response. The client can then compare the previous attributes with what it thought the previous attributes were and detect the changes.