As of version 3.2.1, nfs monitoring has undergone a major change. Unlike the old behavior which
only reported on the client or server for a specific version, by default nfs reporting now collects
data for all types of nfs data including nfs version 4. This also means when reporting nfs
summary data, all statistics are aggregated in both brief and summary formats.
A system typically runs one version of NFS and usually
acts as a client or server and so by aggregating the data the numbers being reported in brief mode
will already be for a single type of data. Furthermore, in verbose mode the client/server data are
broken out so even if the system is acting as both a client and server you will be able to
differentiate the data being reported.
As an optimization as well as a convenience, collectl looks at the raw read/write fields for
each set of nfs data, which represent the totals since boot.
If those fields are both 0, it is assumed there is no nfs activity and the rest of
the statistics will also assumed to be zero. With the excepion of the detail format
descripted later, this all happens behind the scenes. However, just because those fields are
non-zero does not mean there is currently nfs activity. In fact if you mount a filesystem, write
to it and dismount it, those counters will remain non-zero until the system is rebooted. In other
words, this approach is not perfect but simply provided as a mechanism to help reduce the
need for user-specified filters to help focus the detail output.
As they say, your mileage may vary and if your system is running mixed nfs versions and/or
acting as a client and server and you really only want a subset of the activity included in
the summary or detail reports, you can modify the behavior by specifying one or more filters with
the --nfsfilt switch. If you just select clients, only data for those clients will be included
in brief, summary and detail formats. However, if recording to a raw file, collectl
will record data for all NFS client versions even if you've only selected one or two. The same holds
true for servers. When you do use -nfsfilt, those values are display in the brief and verbose
headers both during collection and playback.
The data collected for NFS V2 and V3 is quiet similar in that V3 reports of superset of what V2 reports
with the exception of root and wrcache. V4 reports a lot more counters than either
but many of the same key ones as V3 and so the detail format has been standardized on the V3 counters.
In this mode, one line is reported for each of the 6 types, with blank entries for the non-common fields
as shown here. Note that only rows for those types determined to be active by checking the
read/write fields or explicitly selected through filters, will be included:
# NFS SERVER/CLIENT DETAILS (/sec)
#Type Read Writ Comm Look Accs Gttr Sttr Rdir Cre8 Rmov Rnam Link Rlnk Null Syml Mkdr Rmdr Fsta Finf Path Mknd Rdr+
Clt2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Svr2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Clt3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Svr3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Clt4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Svr4 0 0 0 0 0 0 0 0 0 0 0 0 0
|Looking at detail data for more than one type of data can be difficult to watch.
Consider using --home which can give the feel of a real-time display in top format.|
Playing back data generated by older versions of collectl
Collectl is smart enough to do the right thing. In other words if you're playing back data generated
by a pre-3.2.1 version of collectl, collectl figures out what type of data the file contains and actually
sets --nfsfilt for you (in fact it won't let you select it yourself) and only displays the type
of data in the file.
Playing back newer data with older versions of collectl
Any raw file created by Version 3.2.1 or greater records nfs data in a format that will not
be recognized by earlier versions of collectl and any attempts to read it will result in fields of all
zeros. It is not expected that this would typically happen but as they say, it is being stated here