Frequently Asked Questions

A: Here is the trace format.

A: Yes, they are available here.

A:

• sum: a summary of the operation counts. These are formatted to look like the output from nfsstat on a particular system, now obsolete. It would be better to reformat these in a regular, easy-to-parse manner.

• txt.gz: the output from nfsdump. This is what people want.

• gz.ck: the output of cksum for the corresponding txt.gz. Useful for making sure that the download wasn't corrupted somehow.

A: The names for the various fields in the NFS XDR messages are not always intuitive! And to make matters worse, my mappings of those names to the names used in the output of nfsdump are clumsy in places.

Three particular causes of confusion:

1. size/count: in read and write responses, "size" is the size of the file operated on, and "count" is the number of bytes actually read/written by the operation.

2. uid/euid and gid/egid: The uid/gid of a file system object refer to the uid/gid of the owner of that object, as described in the NFS protocol.

   The euid/egid are not part of the NFS protocol itself, but are part of the underlying RPC protocol, and refer to the effective uid/gid of the client making the request. These are used (in RPC) by the server to determine whether or not the client has the authority to make the request. In this context, they can be used to give a rough idea who the caller is.

3. Many NFS requests and some responses have "optional" fields. For example, the "set attribute" request can set many different attributes, but the caller usually only wants to set one or two, and omits the others. Similarly, the server may choose to include or omit "extra" stat info about files as part of its responses. When this occurs, nothing appears in the output of nfsdump for that field. This means that it is a very bad idea to write code that makes assumptions about the position of each field in the output. Resist the urge to assume that the same field appears at the same position every time!

   It would have been a better design to have all fields always present, and have a special nil value for fields that were omitted. Too late now, unfortunately.