内に含ま
その他のドキュメント
サポート リソース
| PDF 文書ファイルをダウンロードする
NFS Overview
1
- 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 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:
-
- 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.
- The application reads the data set from the (remote) disk.
- 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).
- 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 software environment is shipped with both NFS Version 2 and NFS Version 3. NFS Version 3 is a new addition to the Solaris 2.5 and later software environment.s You tune NFS Version 2 and NFS Version 3 in a similar manner.
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 NFS Version 3 allows 64-bit file sizes, which gives you access to files over 4 Gbytes. However, although NFS Version 3 allows access to file larger than 4 Gbytes, that only works if both the client and the server the operating systems have sufficient hooks. Currently, the software environment (up through the Solaris 2.5.1 software environment), does not have these hooks.
-
Asynchronous Writes NFS Version 3 can use asynchronous writes, which is optional. The NFS Version 3 client sends asynchronous writes requests to the server who 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 wishes to free its copy, it notifies the server with a COMMIT operation. The server responds positively only after it ensures the data has been written to stable storage. Otherwise, it responds with an error and the client resends the data synchronously.
- The advantages of asynchronous writes is that by allowing the server to determine the best policy to sync the data and the high likelihood that it has been synchronized by the time the COMMIT arrives. Compared with NFS Version 2, this scheme allows for 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, a ls or an ls -l triggers them. When the ls -l commands runs over Version 3, the file handles and attributes are returned with the list of names in the directory. With Version 2, the names are returned first, then additional calls to the server are needed to get the file handles and attributes.
- The advantage with the READDIRPLUS operation in Version 3 is than an ls and an ls -l now are comparable in speed due to the saving in not having to send separate GETATTR requests 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 allows the client to detect if another client has changed the data between its last access and the current request. This is accomplished by having the server send 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 changes.
Third-Party Tools
- Some of the third party tools you can use for NFS and networks include:
-
-
(TM) · NetMetrix (Hewlett-Packard)
-
(TM) · SharpShooter (AIM Technology)
- SharpShooter (Version 3) understands the NFS Version 3 protocol.
|
|