CHAPTER 1

NFS Overview

---

This chapter briefly discusses NFS characteristics, the tuning cycle, and third-party tools used to monitor NFS activity.

---

NFS Characteristics

The NFS environment provides transparent file access to remote files over a network. File systems of remote devices appear to be local. Clients access remote file systems by using either the mount command or the automounter.

The NFS protocol enables multiple client retries and easy crash recovery. The client provides all of the information for the server to perform the requested operation. The client retries the request until it is acknowledged by the server, or until it times out. The server acknowledges writes when the data is flushed to nonvolatile storage.

The multithreaded kernel does not require the maintenance of multiple nfsd or asynchronous-block I/O daemon(biod) processes; they are both implemented as operating system kernel threads. There are no biods on the client and one nfsd process exists on the server.

NFS traffic is characterized by its random patterns. NFS requests, which are usually of many types, are generated in bursts. The capacity of an NFS server must address the bursty nature of NFS file service demands. Demand varies widely but is relatively predictable during normal activity.

Most requests from applications (which may be local or remote), follow this pattern:

1. The user reads in the sections of the application binary then executes the code pages leading to a user dialog, which specifies a data set on which to operate.

2. The application reads the data set from the remote disk.

3. The user can then interact with the application, manipulating the in-memory representation of the data. This phase continues for most of the runtime of the application.

4. The modified data set is saved to disk.

---

Note - More sections of the application binary may be paged in as the application continues to run.

---

---

NFS Version 2 and Version 3

The Solaris 2.5 through 2.6 software environments are shipped with NFS Version 2 and NFS version 3. NFS version 3 is a new addition to the Solaris 2.x software 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 Features

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.

A discussion of the main features of NFS version 3 follows.

64-Bit File Size

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 2.6 software environment is the first Solaris release that takes advantage of this protocol feature. Operating systems prior to Solaris 2.6 did not have 64-bit file support.

The limit for the UNIX File System in the Solaris 2.6 software environment is 1 Terrabyte (40 bits).

Asynchronous Writes

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.

Read Directory with Attributes

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.

Weak Cache Consistency

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.

---

Tuning Cycle

FIGURE 1-1 shows a flowchart of the tuning cycle:

FIGURE 1-1

---

Third Party Tools

Some of the third party tools you can use for NFS and networks include:

• NetMetrix (Hewlett-Packard)
• SharpShooter (AIM Technology)

SharpShooter (version 3) understands the NFS version 3 protocol.