Managing NFS and NIS 2nd phần 9 pps

Managing NFS and NIS 325 Table 14-3 defines the values for the logging files when filesystems are shared with the various tags. Table 14-3. Logging files under different tags Tag Log fhtable Buffer global /var/nfs/logs/nfslog /var/nfs/workfiles/fhtable /var/nfs/workfiles/ nfslog_workbuffer eng /export/eng/logs/nfslog /var/nfs/workfiles/fhtable /var/nfs/workfiles/ nfslog_workbuffer corp /export/corp/logging/logs/nfslog /export/corp/logging/workfiles/fhtable /export/corp/logging/ workfiles/nfslog_workbuffer extended /var/nfs/extended_logs/nfslog /var/nfs/workfiles/fhtable /var/nfs/workfiles/ nfslog_workbfuffer The temporary work buffers can grow large in a hurry, therefore it may not be a good idea to keep them in the default directory /var/nfs, especially when /var is fairly small. It is recommended to either spread them out among the filesystems they monitor, or place them in a dedicated partition. This will allow space in your /var partition to be used for other administration tasks, such as storing core files, printer spool directories, and other system logs. 14.6.3.1 Basic versus extended log format Logging using the basic format only reports file uploads and downloads. On the other hand, logging using the extended format provides more detailed information of filesystem activity, but may be incompatible with existing tools that process WU-Ftpd logs. Tools that expect a single character identifier in the operation field will not understand the multicharacter description of the extended format. Home-grown scripts can be easily modified to understand the richer format. Logging using the extended format reports directory creation, directory removal, and file removal, as well as file reads (downloads) and file writes (uploads). Each record indicates the NFS version and protocol used during access. Let us explore the differences between the two logs by comparing the logged information that results from executing the same sequence of commands against the NFS server zeus. First, the server exports the filesystem using the extended tag previously defined in the /etc/nfs/nfslog.conf file: zeus# share -o log=extended /export/home Next, the client executes the following sequence of commands: rome% cd /net/zeus/export/home rome% mkdir test rome% mkfile 64k 64k-file rome% mv 64k-file test rome% rm test/64k-file rome% rmdir test rome% dd if=128k-file of=/dev/null 256+0 records in 256+0 records out The resulting extended format log on the server reflects corresponding NFS operations: Managing NFS and NIS 326 zeus# cat /var/nfs/extended_logs/nfslog Mon Jul 31 11:00:05 2000 0 rome 0 /export/home/test b _ mkdir r 19069 nfs3- tcp 0 * Mon Jul 31 11:00:33 2000 0 rome 0 /export/home/64k-file b _ create r 19069 nfs3- tcp 0 * Mon Jul 31 11:00:33 2000 0 rome 65536 /export/home/64k-file b _ write r 19069 nfs3-tcp 0 * Mon Jul 31 11:00:49 2000 0 rome 0 /export/home/64k-file- >/export/home/test/64k- file b _ rename r 19069 nfs3-tcp 0 * Mon Jul 31 11:00:59 2000 0 rome 0 /export/home/test/64k-file b _ remove r 19069 nfs3-tcp 0 * Mon Jul 31 11:01:01 2000 0 rome 0 /export/home/test b _ rmdir r 19069 nfs3- tcp 0 * Mon Jul 31 11:01:47 2000 0 rome 131072 /export/home/128k-file b _ read r 19069 nfs3-tcp 0 * Notice that the mkfile operation generated two log entries, a 0-byte file, create, followed by a 64K write. The rename operation lists the original name followed by an arrow pointing to the new name. File and directory deletions are also logged. The nfs3-tcp field indicates the protocol and version used: NFS Version 3 over TCP. Now let us compare against the basic log generated by the same sequence of client commands. First, let us reshare the filesystem with the basic log format. It is highly recommended to never mix extended and basic log records in the same file. This will make post-processing of the log file much easier. Our example places extended logs in /var/nfs/extended_logs/nfslog and basic logs in /var/nfs/logs/nfslog: zeus# share -o log /export/home Next, the client executes the same sequence of commands listed earlier. The resulting basic format log on the server only shows the file upload (incoming operation denoted by i) and the file download (outgoing operation denoted by o). The directory creation, directory removal, and file rename are not logged in the basic format. Notice that the NFS version and protocol type are not specified either: zeus# cat /var/nfs/logs/nfslog Mon Jul 31 11:35:08 2000 0 rome 65536 /export/home/64k-file b _ i r 19069 nfs 0 * Mon Jul 31 11:35:25 2000 0 rome 131072 /export/home/128k-file b _ o r 19069 nfs 0 * 14.6.4 The nfslogd daemon It is the nfslogd daemon that generates the ultimate NFS log file. The daemon periodically wakes up to process the contents of the work buffer file created by the kernel, performs hostname and pathname mappings, and generates the file transfer log record. Since the filesystem can be reshared with logging disabled, or simply be unshared, the nfslogd daemon cannot rely on the list of exported filesystems to locate the work buffer files. So how exactly does the nfslogd daemon locate the work buffer files? Managing NFS and NIS 327 When a filesystem is exported with logging enabled, the share command adds a record to the /etc/nfs/nfslogtab file indicating the location of the work buffer file, the filesystem shared, the tag used to share the filesystem, and a 1 to indicate that the filesystem is currently exported with logging enabled. This system table is used to keep track of the location of the work buffer files so they can be processed at a later time, even after the filesystem is unshared, or the server is rebooted. The nfslogd daemon uses this system file to find the location of the next work buffer file that needs to be processed. The daemon removes the /etc/nfs/nfslogtab entry for the work buffer file after processing if the corresponding filesystem is no longer exported. The entry will not be removed if the filesystem remains exported. The nfslogd daemon removes the work buffer file once it has processed the information. The kernel creates a new work buffer file when more RPC requests arrive. To be exact, the work buffer file currently accessed by the kernel has the _in_process string appended to its name (name specified by the buffer parameter in /etc/nfs/nfslog.conf ). The daemon, asks the kernel to rename the buffer to the name specified in the configuration file once it is ready to process it. At this point the kernel will again create a new buffer file with the string appended and start writing to the new file. This means that the kernel and the nfslogd daemon are always working on their own work buffer file, without stepping on each others' toes. The nfslogd daemon will remove the work buffer file once it has processed the information. You will notice that log records do not show up immediately on the log after a client accesses the file or directory on the server. This occurs because the nfslogd daemon waits for enough RPC information to gather in the work buffer before it can process it. By default it will wait five minutes. This time can be shortened or lengthened by tuning the value of IDLE_TIME in /etc/default/nfslogd. 14.6.4.1 Consolidating file transfer information The NFS protocol was not designed to be a file transfer protocol, instead it was designed to be a file access protocol. NFS file operations map nicely to Unix filesystem calls and as such, its file data access and modification mechanisms operate on regions of files. This enables NFS to minimize the amount of data transfer required between server and client, when only small portions of the file are needed. The NFS protocol enables reads and writes of arbitrary number of bytes at any given offset, in any given order. NFS clients are not required to read a file on an NFS server in any given order, they may start in the middle and read an arbitrary number of bytes at any given offset. The random byte access, added to the fact that NFS Versions 2 and 3 do not define an open or close operation, make it hard to determine when an NFS client is done reading or writing a file. Despite this limitation, the nfslogd daemon does a decent job identifying file transfers by using various heuristics to determine when to generate the file transfer record. 14.6.5 Filehandle to path mapping Most NFS operations take a filehandle as an argument, or return a filehandle as a result of the operation. In the NFS protocol, a filehandle serves to identify a file or a directory. Filehandles contain all the information the server needs to distinguish an individual file or directory. To the client, the filehandle is opaque. The client stores the filehandles for use in a later request. It is the server that generates the filehandle: Managing NFS and NIS 328 1 0.00000 rome -> zeus NFS C LOOKUP3 FH=0222 foo.tar.Z 2 0.00176 zeus -> rome NFS R LOOKUP3 OK FH=EEAB 9 0.00091 rome -> zeus NFS C READ3 FH=EEAB at 0 for 32768 Consider packets 1, 2, and 9 from the snoop trace presented earlier in this chapter. The client must first obtain the filehandle for the file foo.tar.Z, before it can request to read its contents. This is because the NFS READ procedure takes the filehandle as an argument and not the filename. The client obtains the filehandle by first invoking the LOOKUP procedure, which takes as arguments the name of the file requested and the filehandle of the directory where it is located. Note that the directory filehandle must itself first be obtained by a previous LOOKUP or MOUNT operation. Unfortunately, NFS server implementations today do not provide a mechanism to obtain a filename given a filehandle. This would require the kernel to be able to obtain a path given a vnode, which is not possible today in Solaris. To overcome this limitation, the nfslogd daemon builds a mapping table of filehandle to pathnames by monitoring all NFS operations that generate or modify filehandles. It is from this table that it obtains the pathname for the file transfer log record. This filehandle to pathname mapping table is by default stored in the file /var/nfs/fhtable. This can be overridden by specifying a new value for fhtable in /etc/nfs/nfslog.conf. In order to successfully resolve all filehandles, the filesystem must be shared with logging enabled from the start. The nfslogd daemon will not be able to resolve all mappings when logging is enabled on a previously shared filesystem for which clients have already obtained filehandles. The filehandle mapping information can only be built from the RPC information captured while logging is enabled on the filesystem. This means that if logging is temporarily disabled, a potentially large number of filehandle transactions will not be captured and the nfslogd daemon will not be able to reconstruct the pathname for all filehandles. If a filehandle can not be resolved, it will be printed on the NFS log transaction record instead of printing the corresponding (but unknown) pathname. The filehandle mapping table needs to be backed by permanent storage since it has to survive server reboots. There is no limit for the amount of time that NFS clients hold on to filehandles. A client may obtain a filehandle for a file, read it today and read it again five days from now without having to reacquire the filehandle (not encountered often in practice). Filehandles are even valid across server reboots. Ideally the filehandle mapping table would only go away when the filesystem is destroyed. The problem is that the table can get pretty large since it could potentially contain a mapping for every entry in the filesystem. Not all installations can afford reserving this much storage space for a utility table. Therefore, in order to preserve disk space, the nfslogd daemon will periodically prune the oldest contents of the mapping table. It removes filehandle entries that have not been accessed since the last time the pruning process was performed. This process is automatic, the nfslogd daemon will prune the table every seven days by default. This can be overridden by setting PRUNE_TIMEOUT in /etc/default/nfslogd. This value specifies the number of hours between prunings. Making this value too small can increase the risk that a client may have held on to a filehandle longer than the PRUNE_TIMEOUT and perform an NFS operation after the filehandle has been removed from the table. In such a case, the nfslogd daemon will not be able to resolve the pathname and the NFS log will include the Managing NFS and NIS 329 filehandle instead of the pathname. Pruning of the table can effectively be disabled by setting the PRUNE_TIMEOUT to INT_MAX. Be aware that this may lead to very large tables, potentially causing problems exceeding the database maximum values. This is therefore highly discouraged, since in practice the chance of NFS clients holding on to filehandles for more than a few days without using them is extremely small. The nfslogd daemon uses ndbm [4] to manage the filehandle mapping table. [4] See dbm_clearerr(3C). 14.6.6 NFS log cycling The nfslogd daemon periodically cycles the logs to prevent an individual file from becoming extremely large. By default, the ten most current NFS log files are located in /var/nfs and named nfslog, nfslog.0, through nfslog.9. The file nfslog being the most recent, followed by nfslog.1 and nfslog.9 being the oldest. The log files are cycled every 24 hours, saving up to 10 days worth of logs. The number of logs saved can be increased by setting MAX_LOGS_PRESERVE in /etc/default/nfslogd. The cycle frequency can be modified by setting CYCLE_FREQUENCY in the same file. 14.6.7 Manipulating NFS log files Sometimes it may be desirable to have the nfslogd daemon close the current file, and log to a fresh new file. The daemon holds an open file descriptor to the log file, so renaming it or copying it somewhere else may not achieve the desired effect. Make sure to first shut down the daemon before manipulating the log files. To shut down the daemon, send it a SIGHUP signal. This will give the daemon enough time to flush pending transactions to the log file. You can use the Solaris pkill command to send the signal to the daemon. Note that the daemon can take a few seconds to flush the information: # pkill -HUP -x -u 0 nfslogd Sending it a SIGTERM signal will simply close the buffer files, but pending transactions will not be logged to the file and will be discarded. 14.6.8 Other configuration parameters The configuration parameters in the /etc/default/nfslogd tune the behavior of the nfslogd daemon. The nfslogd daemon reads the configuration parameters when it starts, therefore any changes to the parameters will take effect the next time the daemon is started. Here is a list of the parameters: UMASK Used to set the file mode used to create the log files, work buffer files, and filehandle mapping tables. Needless to say one has to be extremely careful setting this value, as it could open the doors for unathorized access to the log and work files. The default is 0x137, which gives read/write access to root, read access to the group that started the nfslogd daemon, and no access to other. Managing NFS and NIS 331 MAPPING_UPDATE_INTERVAL Specifies the time interval, in seconds, between updates of the records in the filehandle mapping table. Ideally the access time of entries queried in the mapping table should be updated on every access. In practice, updates of this table are much more expensive than queries. Instead of updating the access time of a record each time the record is accessed, the access time is updated only when the last update is older than MAPPING_UPDATE_INTERVAL seconds. By default updates are performed once per day. Make sure this value is always less than the value specified by PRUNE_TIMEOUT, otherwise all of the entries in the filehandle mapping tables will be considered timed out. PRUNE_TIMEOUT Specifies how frequent the pruning of the filehandle mapping tables is invoked. This value represents the minimum number of hours that a record is guaranteed to remain in the mapping table. The default value of seven days (168 hours) instructs the nfslogd daemon to perform the database pruning every seven days and remove the records that are older than seven days. Note that filehandles can remain in the database for up to 14 days. This can occur when a record is created immediately after the pruning process has finished. Seven days later the record will not be pruned because it is only six days and hours old. The record will be removed until the next pruning cycle, assuming no client accesses the filehandle within that time. The MAPPING_UPDATE_INTERVAL may need to be updated accordingly. 14.6.9 Disabling NFS server logging Unfortunately, disabling logging requires some manual cleanup. Unsharing or resharing a filesystem without the -o log directive stops the kernel from storing information into the work buffer file. You must allow the nfslogd daemon enough time to process the work buffer file before shutting it down. The daemon will notice that it needs to process the work buffer file once it wakes up after its IDLE_TIME has been exceeded. Once the work buffer file has been processed and removed by the nfslogd daemon, the nfslogd daemon can manually be shutdown by sending it a SIGHUP signal. This allows the daemon to flush the pending NFS log information before it is stopped. Sending any other type of signal may cause the daemon to be unable to flush the last few records to the log. There is no way to distinguish between a graceful server shutdown and the case when logging is being completely disabled. For this reason, the mapping tables are not removed when the filesystem is unshared, or the daemon is stopped. The system administrator needs to remove the filehandle mapping tables manually when he/she wants to reclaim the filesystem space and knows that logging is being permanently disabled for this filesystem. [5] [5] Keep in mind that if logging is later reenabled, there will be some filehandles that the nfslogd daemon will not be able to resolve since they were obtained by clients while logging was not enabled. If the filehandle mapping table is removed, then the problem is aggravated. 14.7 Time synchronization Distributing files across several servers introduces a dependency on synchronized time of day clocks on these machines and their clients. Consider the following sequence of events: Managing NFS and NIS 332 caramba % date Mon Sep 25 18:11:24 PDT 2000 caramba % pwd /home/labiaga caramba % touch foo caramba % ls -l foo -rw-r r 1 labiaga staff 0 Sep 25 18:18 foo aqua % date Mon Sep 25 17:00:01 PDT 2000 aqua % pwd /home/labiaga aqua % ls -l foo -rw-r r 1 labiaga staff 0 Sep 25 2000 foo aqua % su aqua # rdate caramba Mon Sep 25 18:16:51 2000 aqua % ls -l foo -rw-r r 1 labiaga staff 0 Sep 25 18:18 foo On host caramba, a file is created that is stamped with the current time. Over on host aqua, the time of day clock is over an hour behind, and file foo is listed with the month-day-year date format normally reserved for files that are more than six months old. The problem stems from the time skew between caramba and aqua: when the ls process on aqua tries to determine the age of file foo, it subtracts the file modification time from the current time. Under normal circumstances, this produces a positive integer, but with caramba 's clock an hour ahead of the local clock, the difference between modification time and current time is a negative number. This makes file foo a veritable Unix artifact, created before the dawn of Unix time. As such, its modification time is shown with the "old file" format. [6] [6] Some Unix utilities have been modified to handle small time skews in a graceful manner. For example, ls tolerates clock drifts of a few minutes and correctly displays file modification times that are slightly in the future. Time of day clock drift can be caused by repeated bursts of high priority interrupts that interfere with the system's hardware clock or by powering off (and subsequently booting) a system that does not have a battery-operated time of day clock. [7] [7] The hardware clock, or "hardclock" is a regular, crystal-driven timer that provides the system heartbeat. In kernel parlance, the hardclock timer interval is a "tick," a basic unit of time-slicing that governs CPU scheduling, process priority calculation, and software timers. The software time of day clock is driven by the hardclock. If the hardclock interrupts at 100 Hz, then every 100 hardclock interrupts bump the current time of day clock by one second. When a hardclock interrupt is missed, the software clock begins to lose time. If there is a hardware time of day clock available, the kernel can compensate for missed hardclock interrupts by checking the system time against the hardware time of day clock and adjusting for any drift. If there is no time of day clock, missed hardware clock interrupts translate into a tardy system clock. In addition to confusing users, time skew wreaks havoc with the timestamps used by make, jobs run out of cron that depend on cron-started processes on other hosts, and the transfer of NIS maps to slave servers, which fail if the slave server's time is far enough ahead of the master server. It is essential to keep all hosts sharing filesystems or NIS maps synchronized to within a few seconds. rdate synchronizes the time of day clocks on two hosts to within a one-second granularity. Because it changes the local time and date, rdate can only be used by the superuser, just as the date utility can only be used by root to explicitly set the local time. rdate takes the name of the remote time source as an argument: % rdate mahimahi couldn't set time of day: Not owner Managing NFS and NIS 333 % su # rdate mahimahi Mon Sep 25 18:16:51 2000 One host is usually selected as the master timekeeper, and all other hosts synchronize to its time at regular intervals. The ideal choice for a timekeeping host is one that has the minimum amount of time drift, or that is connected to a network providing time services. If the time host's clock loses a few seconds each day, the entire network will fall behind the real wall clock time. All hosts agree on the current time, but this time slowly drifts further and further behind the real time. While the remote host may be explicitly specified, it is more convenient to create the hostname alias timehost in the NIS hosts file and to use the alias in all invocations of rdate: 131.40.52.28 mahimahi timehost 131.40.52.26 wahoo 131.40.52.150 kfir Some systems check for the existence of the hostname timehost during the boot sequence, and perform an rdate timehost if timehost is found. This convention is particularly useful if you are establishing a new timekeeping host and you need to change its definition if your initial choice proves to be a poor time standard. It is far simpler to change the definition of timehost in the NIS hosts map than it is to modify the invocations of rdate on all hosts. Time synchronization may be performed during the boot sequence, and at regular intervals using cron. The interval chosen for time synchronization depends on how badly each system's clock drifts: once-a-day updates may be sufficient if the drift is only a few seconds a day, but hourly synchronization is required if a system loses time each hour. To run rdate from cron, add a line like the following to each host's crontab file: Hourly update: 52 * * * * rdate timehost > /dev/null 2>&1 Daily update: 52 1 * * * rdate timehost > /dev/null 2>&1 The redirection of the standard output and standard error forces rdate 's output to /dev/null, suppressing the normal echo of the updated time. If a cron-driven command writes to standard output or standard error, cron will mail the output to root. To avoid swamping the timehost with dozens of simultaneous rdate requests, the previous example performs its rdate at a random offset into the hour. A common convention is to use the last octet of the machine's IP address (mod 60) as the offset into the hour, effectively scattering the rdate requests throughout each hour. The use of rdate ensures a gross synchronization accurate to within a second or two on the network. The resolution of this approach is limited by the rdate and cron utilities, both of which are accurate to one second. This is sufficient for many activities, but finer Managing NFS and NIS 334 synchronization with a higher resolution may be needed. The Network Time Protocol (NTP) provides fine-grain time synchronization and also keeps wide-area networks in lock step. NTP is outside the scope of this book. [...]... Destination address = 131.40.52.223, caramba No options NFS: NFS: NFS: NFS: NFS: NFS: NFS: NFS: NFS: - Sun NFS Proc = 1 (Get file attributes) Status = 0 (OK) File type = 2 (Directory) Mode = 0755 Setuid = 0, Setgid = 0, Sticky = 0 Owner's permissions = rwx Group's permissions = r-x 344 Managing NFS and NIS NFS: NFS: NFS: NFS: NFS: NFS: NFS: NFS: NFS: NFS: Other's permissions = r-x Link count = 4, User... 20:01 data2 7 8 9 10 11 12 13 14 15 16 17 18 0.000 39 0.00 198 0.00031 0.00220 0.00033 0.00000 0.00000 0.00000 0.00035 0.00211 0.00032 0.00 191 tarsus inchun tarsus inchun tarsus inchun tarsus inchun tarsus inchun tarsus inchun -> -> -> -> -> -> -> -> -> -> -> -> inchun tarsus inchun tarsus inchun tarsus inchun tarsus inchun tarsus inchun tarsus NFS NFS NFS NFS NFS NFS NFS NFS NFS NFS NFS NFS C R C R C... id = 7 497 9 Last access time = 03-Oct-00 00:41:55.160003000 GMT Modification time = 01-Oct-00 19: 16:32. 399 997 000 GMT Attribute change time = 01-Oct-00 19: 16:32. 399 997 000 GMT Along with other file attributes, the NFS portion of the packet contains the mode bits for owner, group and other These mode bits were the same as those reported by the ls -la command, so the problem was not caused by the NFS server... 50171 NFS: 95 50 496 NFS: 199 51032 data1 NFS: 201 51706 data2 NFS: 4 entries NFS: EOF = 1 NFS: The directory contents are cached by tarsus, so that they may be reused in a future directory listing The NFS Lookup and NFS Getattr requests, along with their corresponding replies in packets 11 thru 18, result from the long listing of the directory requested by ls -l An NFS Lookup obtains the filehandle... 20:45:10.88 NFS: - Sun NFS NFS: NFS: Proc = 1 (Get file attributes) NFS: Status = 0 (OK) NFS: File type = 2 (Directory) NFS: Mode = 040777 NFS: Type = Directory NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = rwx NFS: Group's permissions = rwx NFS: Other's permissions = rwx NFS: Link count = 2, UID = 0, GID = -2, Rdev = 0x0 NFS: File size = 512, Block size = 512, No of blocks = 1 NFS: ... GETATTR2 FH=FA14 NFS R GETATTR2 OK NFS C GETATTR2 FH=F66F 342 Managing NFS and NIS 47 48 49 0.00 191 0.00032 0.00214 inchun -> tarsus tarsus -> inchun inchun -> tarsus NFS R GETATTR2 OK NFS C GETATTR2 FH=F8CD NFS R GETATTR2 Stale NFS file handle The directory attributes reported in packet 45 are the same as those seen in packet 40, therefore tarsus assumes that it can safely use the cached filehandles associated... writes using the raw device mechanism (pread/s & pwrit/s): # sar -b 20 5 SunOS bunker 5.8 Generic sun4u 12/06/2000 10: 39: 01 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s 10: 39: 22 19 252 93 34 103 67 0 0 10: 39: 43 21 612 97 46 314 85 0 0 10:40:03 20 430 95 35 2 19 84 0 0 10:40:24 35 737 95 49 323 85 0 0 10:40:45 21 701 97 60 3 89 85 0 0 Average 23 546 96 45 270 83 0 0 In practice, a cache... to the Solaris 8 NFS Server Performance and Tuning Guide for Sun Hardware (February 2000) • • • 2 nfsd threads for each active client process 16 to 32 nfsd threads for each CPU 16 nfsd threads per 10Mb network or 160 per 100Mb network 3 59 Managing NFS and NIS 16.5.3 Memory usage NFS uses the server's page cache (in SunOS 4.x, Solaris and System V Release 4) for file blocks read in NFS read requests... clients, and the servers The next few chapters present NFS tuning and benchmarking techniques 348 Managing NFS and NIS Chapter 16 Server-Side Performance Tuning Performance analysis and tuning, particularly when it involves NFS and NIS, is a topic subject to heated debate The focus of the next three chapters is on the analysis techniques and configuration options used to identify performance bottlenecks and. .. NFS and NIS requests, but haven't really looked at how they are generated in "live" environments NFS requests exhibit randomness in two ways: they are typically generated in bursts, and the types of requests in each burst usually don't have anything to do with each other It is very 3 49 Managing NFS and NIS rare to have a steady, equally spaced stream of requests arriving at any server The typical NFS . NFS log files are located in /var /nfs and named nfslog, nfslog.0, through nfslog .9. The file nfslog being the most recent, followed by nfslog.1 and nfslog .9 being the oldest. The log files. r 190 69 nfs3 -tcp 0 * Mon Jul 31 11:00: 59 2000 0 rome 0 /export/home/test/64k-file b _ remove r 190 69 nfs3 -tcp 0 * Mon Jul 31 11:01:01 2000 0 rome 0 /export/home/test b _ rmdir r 190 69 nfs3 - tcp. the filehandle: Managing NFS and NIS 328 1 0.00000 rome -> zeus NFS C LOOKUP3 FH=0222 foo.tar.Z 2 0.00176 zeus -> rome NFS R LOOKUP3 OK FH=EEAB 9 0.00 091 rome -> zeus NFS C READ3