Skip to content


Subversion checkout URL

You can clone with
Download ZIP
command line tool to check NFS server response times
C Logos Perl Makefile
Branch: master
Failed to load latest commit information.
Smokeping add option for TCP, from
mansrc add -Q option for rquota to nfsping manpage
parson first go at converting parse_fh() to read json using parson
rpcsrc add NULL procedure to rquota
.gitignore use globs for rpcsrc
INSTALL simple make install and INSTALL file
LICENSE update copyright to 2015
Makefile build rquota rpc files
README add support for rquota protocol to nfsping
nfsping.spec Update changelog with recent modifications


$ nfsping -c 5 filer1 filer2
filer1 : [0], 0.52 ms (0.52 avg, 0% loss)
filer2 : [0], 1.12 ms (1.12 avg, 0% loss)
filer1 : [1], 0.35 ms (0.43 avg, 0% loss)
filer2 : [0], 0.98 ms (1.05 avg, 0% loss)
filer1 : [2], 0.36 ms (0.41 avg, 0% loss)
filer2 : [0], 1.67 ms (1.26 avg, 0% loss)
filer1 : [3], 1.18 ms (0.60 avg, 0% loss)
filer2 : [0], 1.23 ms (1.25 avg, 0% loss)
filer1 : [4], 0.33 ms (0.55 avg, 0% loss)
filer2 : [0], 1.36 ms (1.27 avg, 0% loss)

filer1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.33/0.55/1.18
filer2 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.98/1.27/1.67

NFSping is an open source (BSD licensed) command line utility for Linux and other POSIX operating systems which measures the availability and response times of an NFS server by sending probe packets. It's based on the fping ( program's interface but doesn't share any code with that project. It's written in C and doesn't require any libraries other than libc.

On modern NFS servers, the network stack and filesystem are often being run on separate cores or even hardware components. This means in practise that a fast ICMP ping response isn't indicative of how quickly the NFS services are responding. This tool directly tests the responsiveness of the server's NFS component. It can check all seven of the RPC protocols that are used by NFS: NFS, mount, portmap (rpcbind), the network lock manager (NLM), Sun's ACL sideband protocol, the network status monitor (NSM) and the rquota protocol.

NFSping checks if each target server is responding by sending it a NULL RPC and waiting for a response. Multiple targets specified on the command line will be pinged in round-robin order. The NULL procedure of each protocol is a noop that is implemented for testing. NFSping supports versions 2, 3 and 4 of NFS, and the corresponding versions of the other protocols. By default it doesn't use the RPC portmapper for NFS pings and sends NULL packets to port 2049 using the UDP transport. Use the -T option to use TCP, -M to query the portmapper, or -P to specify a port number.

NFSping can also check the mount protocol response using the -n option. By default it uses the portmapper to discover the port that the mount protocol is bound to on the target. A port can be specified using the -P option.

The -L option will check the network lock manager (NLM) protocol, using the portmapper to discover the port.

The -N option will check the portmap protocol itself (always listening on port 111).

The -a option will check the NFS ACL protocol which usually listens on port 2049 alongside NFS but is a separate RPC protocol.

The -s option will check the network status monitor (NSM) protocol which is used to notify NFS peers of host reboots. The portmapper is used to discover the port.

The -Q option will check the rquota protocol which is used by clients to check and set remote quotas on the server, using the portmapper to discover the port.

To build the nfsping executable:

$ git clone git://
$ cd NFSping && make

`make install` will copy the resulting binary to /usr/local/bin/ (you may need to use `sudo make install`).

In its most basic form it simply reports whether the server is responding to NFS requests:

$ nfsping filer1
filer1 is alive

and exits with a return status of 0, or:

$ nfsping filer1
filer1 : nfsproc3_null_3: RPC: Unable to receive; errno = Connection refused
filer1 is dead

and exiting with a status of 1. This simple form of the command can be built into scripts which just check if the server is up or not without being concerned about a particular response time.

To measure round trip response time (in milliseconds), pass the number of requests to send as an argument to the -c (count) option:

$ nfsping -c 5 filer1
filer1 : [0], 0.09 ms (0.09 avg, 0% loss)
filer1 : [1], 0.16 ms (0.12 avg, 0% loss)
filer1 : [2], 0.15 ms (0.13 avg, 0% loss)
filer1 : [3], 0.16 ms (0.14 avg, 0% loss)
filer1 : [4], 0.12 ms (0.14 avg, 0% loss)

filer1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.09/0.14/0.16

Or to send a continuous sequence of packets (like the traditional ICMP ping command) use the -l (loop) option:

$ nfsping -l filer1

To exit early, use control-c.

It also has a form that produces more easily parsed output when using the -C option:

$ nfsping -C 5 filer1
filer1 : [0], 1.96 ms (1.96 avg, 0% loss)
filer1 : [1], 0.11 ms (1.04 avg, 0% loss)
filer1 : [2], 0.12 ms (0.73 avg, 0% loss)
filer1 : [3], 0.16 ms (0.59 avg, 0% loss)
filer1 : [4], 0.18 ms (0.51 avg, 0% loss)

filer1 : 1.96 0.11 0.12 0.16 0.18

Missed responses are indicated with a dash (-) in the summary output. This form uses more memory since it stores all of the results. In all forms memory is allocated during startup so there should be no increase in memory consumption once running. This format is compatible with fping's output so it can be easily used with Tobi Oetiker's Smokeping ( to produce graphs of response times. There is a module for NFSPing in the standard Smokeping distribution or in the Smokeping subdirectory of the NFSping source.

To only show the summary line, use the -q (quiet) option.

This is a list of the available command-line options:

Usage: nfsping [options] [targets...]
    -a         check the NFS ACL protocol (default NFS)
    -A         show IP addresses
    -c n       count of pings to send to target
    -C n       same as -c, output parseable format
    -d         reverse DNS lookups for targets
    -D         print timestamp (unix time) before each line
    -g string  prefix for graphite metric names (default "nfsping")
    -h         display this help and exit
    -i n       interval between targets (in ms, default 25)
    -l         loop forever
    -L         check the network lock manager (NLM) protocol (default NFS)
    -m         use multiple target IP addresses if found
    -M         use the portmapper (default: NFS no, mount/NLM/NSM yes)
    -n         check the mount protocol (default NFS)
    -N         check the portmap protocol (default NFS)
    -o F       output format ([G]raphite, [S]tatsd, default human readable)
    -p n       pause between pings to target (in ms, default 1000)
    -P n       specify port (default: NFS 2049)
    -q         quiet, only print summary
    -Q         check the rquota protocol (default NFS)
    -r n       reconnect to server every n pings
    -s         check the network status monitor (NSM) protocol (default NFS)
    -S addr    set source address
    -t n       timeout (in ms, default 2500)
    -T         use TCP (default UDP)
    -v         verbose output
    -V n       specify NFS version (2/3/4, default 3)

NFSping can also output stats in a variety of formats for putting into time series databases. Currently only Graphite and StatsD are supported:

$ nfsping -c 5 -oG filer1 401 1370501562 416 1370501563 403 1370501564 410 1370501565 399 1370501566

This is the Graphite plaintext protocol which is <path> <metric> <timestamp>. To avoid floating point numbers, nfsping reports the response time in microseconds (usec).

The default prefix for the Graphite path is "nfsping". This can be changed by specifying a new string as an argument to the -g option. Fully qualified domain names (but not IP addresses) for targets will be reversed:

$ nfsping -c 1 -oG -g filers 292 1409332974

This output can be easily redirected to a Carbon server using nc (netcat):

$ nfsping -l -t1000 -oG filer1 filer2 | nc carbon1 2003

This will send a result every second. Because nfsping is single threaded it's best to set a timeout to stop unresponsive NFS servers from affecting the results when specifying multiple targets. Lost requests will be reported under a separate path, $prefix.$target.$protocol.lost, with a metric of 1.

nc will exit if the TCP connection is reset (such as if the Carbon server is restarted) which will also cause nfsping to exit with a broken pipe. To retry, start a persistent process under a process supervisor like daemontools ( or runit ( which will restart the process if it exits for any reason.

Similarly, the StatsD output will produce plaintext output suitable for sending to StatsD with netcat:

$ nfsping -c 5 -oS filer1|ms|ms|ms|ms|ms

Note that this output uses floating point values, as the StatsD protocol only supports milliseconds. While floating point values are supported by the protocol, some implementations may not handle them. This output has been tested as working with statsite (

Some NFS servers can exhibit varied response times for different TCP connections. This can be due to resource exhaustion on the server, or different network paths taken across a trunked connection. To measure these different responses, use the -r option to force nfsping to close the TCP connection and reconnect to the server after every specified number of pings. Otherwise, new clients connecting to the server may be seeing different behaviour than nfsping's established TCP connection.

NFSping will handle multiple targets and iterate through them on each round. If there are multiple DNS responses for a target, only the first is used. All of them can be checked by using the -m option. The sleep interval between targets can be controlled with the -i option. If any of the targets fail to respond, the command will exit with a status code of 1.

NFSping only performs DNS lookups once during initialisation. If your NFS server's IP addresses change (for example if it's a clustered server and you are using the -m option to resolve multiple addresses), consider using the -c option to exit after sending a certain number of requests and running nfsping under a supervisor to restart it after it exits, where it will do the DNS lookups again.
Something went wrong with that request. Please try again.