NFSTRACE

Section: Maintenance Commands (8)
Updated:
Index Return to Main Contents
 

NAME

nfstrace  

SYNOPSIS

nfstrace [ -- ] [ -c ] [ -t template ] [ -s size ] [ -n sequence-num ] [ -w timeout ] [ -z compress-command ]  

DESCRIPTION

nfstrace takes the output of rpcspy(8) (from stdin) and produces an approximate log of user-level file opens.

The output format consists of 6 vertical-bar-separated fields:
timestamp | direction | file-id | client | transferred | size
where timestamp is the time the open occurred, direction is either read or write, file-id identifies the server and the file handle, client is the client and user that performed the open, transferred is the number of bytes of the file actually read or written (cache hits have a 0 in this field), and size is the size of the file (in bytes).

The file handle to name translation package is not included in the general release version. It is only a rough approximation, but if your application requires it, it is available directly from the author.

Output is normally to the file "nfs.out.nnnnn", where "nnnnn" is a sequence number that is incremented when the file is checkpointed. The file is checkpointed (and any pending reads emitted) every 10000 input records; this parameter may be altered with the -s flag. The name of the file and the beginning sequence number may be specified with the -t and -n flags, respectively. If the -- flag is given, the output is just written to stdout.

The output may be compressed with the -c flag; this causes the output to be piped through "/usr/ucb/compress -c". The name of the compress filter can be specified with -z.

A heuristic is used that assumes that each open for read or write lasts a maximum of two minutes; this time may be altered with the -w flag.

Note that the output is produced out of order. It can be sorted by a post-processor, and each output file can be sorted independently and then concatenated together to produce a chronological trace.  

FILES

nfs.out.nnnnn  

SEE ALSO

rpcspy(8), compress(1)  

BUGS

The output is only an approximation and could be grossly different from what really occurred. In particular, reads from the cache tend to be over-estimated.

Unusual workloads (especially database applications) will fool the program particularly badly.

There should be more control over the level of detail in the output.

The checkpointing frequency is rather approximate.  

AUTHOR

Matt Blaze, mab@cs.princeton.edu


 

Index

NAME
SYNOPSIS
DESCRIPTION
FILES
SEE ALSO
BUGS
AUTHOR

This document was created by man2html, using the manual pages.
Time: 08:12:43 GMT, May 19, 2025