man(1)

✨ man — the nfsometer glow-up guide ✨

okay bestie, pull up a chair 🫶 this is the manual page for nfsometer, and yes we are reading a manual page for fun in the year of our lord. it's giving "girl who actually read the docs" energy and honestly? iconic. let's go 💅

---

🌸 NAME 🌸

nfsometer — NFS performance measurement tool 💖

---

🎀 SYNOPSIS 🎀

nfsometer [options] [mode] [[<server:path>] [workloads...]]

---

🦋 DESCRIPTION 🦋

nfsometer is a whole performance measurement framework, no cap — it runs workloads and reports results across NFS protocol versions, NFS options and Linux NFS client implementations. it's literally built to compare all the things. ✨

---

🌈 MODES 🌈

basic usage (no mode specified, just vibes)

nfsometer <server:path> [workloads...]

this one fetches the needed files, runs traces, and generates reports — same as running the fetch, trace and report stages. one command, three stages, main character energy 👑

advanced usage (you're specifying modes now, look at you)

nfsometer list

lists the contents of the results directory. 🗂️

nfsometer workloads

lists available and unavailable workloads. (yes it tells you the unavailable ones too, it's honest like that 💜)

nfsometer notes

edits the notes file of the results directory. these notes will be displayed in report headers — so say something cute, iykyk.

nfsometer loadgen <server:path> <workload>

runs in loadgen mode: don't record any stats, just loop over <workload> against <server:path>. only one -o option is allowed here, fr fr. use the -n option to run multiple instances of the loadgen workload, and when you're running more than one instance, the initial start times are staggered. 🕰️

nfsometer fetch [workloads...]

fetches all needed files for the specified workload(s). if no workloads are specified, all workloads are fetched. fetched files are only downloaded once and are cached for future runs — efficient queen 🍓

nfsometer trace <server:path> [workloads...]

runs traces against <server:path>. the traces that run will be:

(options + always options + tags) X (workloads) X (num runs)

and it will only run traces that don't already exist in the results directory. no repeats, we don't do that here 💅

nfsometer report

generates all reports available from the results directory. 📊

nfsometer example

shows examples from the man page. hi, that's this page, hello 👋

---

💖 OPTIONS 💖

• -r <dir>, --resultdir=<dir> — the directory used to save results. default: /root/nfsometer_results 📁
• -o <mount.nfs options>, --options=<mount.nfs options> — mount options to iterate through. this option may be used multiple times, and each mount option must have a version specified. periodt.
• -a <mount.nfs options>, --always-options=<mount.nfs options> — options added to every trace. this option may be used multiple times. 🫶
• -t <tags>, --tag=<tags> — tag all new traces with 'tags'. this option may be used multiple times. 🏷️
• -n <num runs>, --num-runs=<num runs> — number of runs for each trace of <options> X <tags> X <workloads>. default: 1
• --serial-graphs — generate graphs inline while generating reports. useful for debugging graphing issues. 🐛
• --rand — randomize the order of traces. 🎲
• -h, --help — show the help message. the classic. ✨

---

🧚 EXAMPLES 🧚

Example 1: See what workloads are available

$ nfsometer workloads

this command lists available workloads and will tell you why workloads are unavailable (if any exist). 💀

Example 2: Compare cthon, averaged over 3 runs, across nfs protocol versions

nfsometer -n 3 server:/export cthon

this example uses the default for -o: "-o v3 -o v4 -o v4.1". to see the results, open results/index.html in a web browser. 🌐

Example 3: Compare cthon, averaged over 3 runs, between v3 and v4.0 only

nfsometer -n 3 -o v3 -o v4 server:/export cthon

this example specifies v3 and v4 only. to see the results, open results/index.html in a web browser. 🌐

Example 4: Compare two kernels running iozone workload, averaged over 2 runs, across all nfs protocol versions

nfsometer can compare two (or more) kernel versions, but has no way of building, installing or booting new kernels. it's up to the user to install new kernels. in order for these kernels to be differentiated, uname -a must be different. 👀

1. boot into kernel #1
2. nfsometer -n 2 server:/export iozone
3. boot into kernel #2
4. nfsometer -n 2 server:/export iozone
5. open results/index.html in a web browser

to see the results, open results/index.html in a web browser. 🌐

Example 5: Using tags

tags (the -t option) can be used to mark nfsometer runs as occurring with some configuration not captured by mount options or detectable tags, such as different sysctl settings (client side), different server side options, or different network conditions. 🏷️

1. set server value foo to 2.3
2. nfsometer -o v4 -o v4.1 -t foo=2.3
3. set server value foo to 10
4. nfsometer -o v4 -o v4.1 -t foo=10

what is passed to -t is entirely up to the user — it will not be interpreted or checked by nfsometer at all, so be careful! 😭

to see the results, open results/index.html in a web browser. 🌐

Example 6: Always options

the -o flag specifies distinct option sets to run, but sometimes there are options that should be present in each. instead of writing each one out, you can use the -a option:

nfsometer -o v3 -o v4 -a sec=krb5 server:/export iozone

this is equivalent to:

nfsometer -o v3,sec=krb5 -o v4,sec=krb5 server:/export iozone

slay. 🫶

Example 7: Using the "custom" workload

a main use case of nfsometer is the "custom" workload — it allows the user to specify the command that nfsometer is to run. 👑

NOTE: the command's cwd (current working directory) is the runroot created on the server.

export NFSOMETER_CMD="echo foo > bar"
export NFSOMETER_NAME="echo"
export NFSOMETER_DESC="Writes 4 bytes to a file"
nfsometer server:/export custom

this will run 3 traces (v3, v4, v4.1) against server:/export of the command: echo foo > bar. 🔥

Example 8: Using the loadgen mode

loadgen runs several instances of a workload without capturing traces. the idea is that you use several clients to generate load, then another client to measure performance of a loaded server. the "real" run of nfsometer (not loadgen) should mark the traces using the -t option. 💜

1. on client A, run the cthon workload to get a baseline of a server without any load.

nfsometer trace server:/export cthon

2. when that's done, start loadgen on client B:

nfsometer -n 10 loadgen server:/export dd_100m_1k

this runs 10 instances of dd_100m_1k workload on server:/export. it can take several minutes to start in an attempt to stagger all the workload instances. ⏳

3. once all instances are started, run the "real" nfsometer trace on client A. use the -t option to mark the traces as having run under load conditions:

nfsometer -t "10_dd" trace server:/export cthon

4. explain how the tests were set up in the result notes. this should be run on client A (which has the traces:

nfsometer notes

5. now generate the reports:

nfsometer report

Example 8: Long running nfsometer trace

(yes bestie, there are two Example 8s. the original said it, so we say it. respect the lore 🌈)

the nfsometer.py script currently runs in the foreground. as such, it will be killed if the tty gets a hangup or the connection to the client is closed. 💀

for the time being, nfsometer should be run in a screen session, or run with nohup and the output redirected to a file.

1. screen -RD
2. nfsometer -n 2 server:/export iozone
3. close terminal window (or ^A^D)
4. ... (yes, literally)
5. reattach later with screen -RD
6. once nfsometer.py is done, results will be in results/index.html

---

👀 SEE ALSO 👀

mountstats, nfsstats

---

💀 BUGS 💀

no known bugs. she's perfect. not a single flaw. 💅✨

---

👑 AUTHOR 👑

Weston Andros Adamson (dros@netapp.com) — thank you for your service 🫡💖

---

and that's the whole page, bestie!! this was nfsometer version 1.9, dated man(1) in the footer, and we simply had to give it a moment. mwah. 🎀✨🦋💖 no cap, go run some traces.