options nosnap 1 # to disable periodic snapshot creation, for reproducibility
options nosnapdir 1 # to avoid inserting .snapshot entry when reading directories
...
1a. Regarding snapshots, many of my development sandboxes are "disposable" so I don't care about snapshots. The first two options might help me. In addition, if I set `snap reserve volX 0`, will that actually turn off snapshots, and reduce overhead on the filer? The options only seem to turn off *automatic* snapshots and the *display* of the ".snapshot" directory.
"options nosnap 1" prevents the filer from doing automatic snapshots, which as the comment says is for reproducibility -- taking a snapshot does chew up some resources, so if one happened during a benchmark run you'd have a blip that might not show up in another run. In any sort of benchmarking, you want to either eliminate any non-deterministic stimuli or use a sample which is large enough to average them out.
"options nosnapdir 1" simply keeps READDIR from returning .snapshot as one of the directory entries. The SFS benchmark initialization writes a bunch of files, then checks to make sure that what it wrote there -- and nothing else -- is present. This simply keeps that initialization check from failing.
options minra 1 # to minimize file read-ahead
...
- What does "options minra 1" buy me? What is the number when
minra=off, the default? (If it's just a boolean, nevermind!) Given I have a development environment with lots of small files, it seems as if turning this option on will benefit me a lot. However, some more information on this would help.
For Data ONTAP 5.0 and later, the default behavior when a read request causes a block to be read from disk is to read that block and the next 71 blocks, a total of 72 blocks (288 KB). "options minra 1" causes the filer to just read the block which is required.
If you do lots of sequential reading of big files, this is usually a good thing because it can amortize the cost of the seek and I/O to the disk over multiple blocks.
If you do lots of short, random reads (think database access) then the read-ahead may be really, really bad because you waste a lot of effort and memory on blocks you don't use.
If you have lots of small files, it doesn't matter, because the filer can't read blocks which don't exist.
SFS often reads short stretches of large files, and has a huge working set (bigger than memory), which is why enable this option for the benchmark.
options udp_lg_dgram.xmit_cksum.offload 1 # to offload checksum computations onto the Gigabit NIC
^^^^^^^ ...
- Does the udp_lg_dgram.xmit_cksum.offload option also apply to
quad-ethernet cards? Will it help if the ports are trunked with a virtual interface?
It's for Gigabit NICs only.
-- Karl Swartz Network Appliance Engineering Work: kls@netapp.com http://www.netapp.com/ Home: kls@chicago.com http://www.chicago.com/~kls/