Todd Merill tmerrill@mathworks.com asks a large number of questions about possible ways of improving filer performance. I will stick to the issues to do with snapshots here.
A general point first;
I was poking around on the SPEC pages, and in the footnotes to the NetApp entries are these parameters:
Several of these are specifically "for reproducibility". If a snapshot or a raid scrub goes off in the middle of your benchmark, it will rather noticably affect the results. This isn't a good reason for not using them in real life. You wouldn't let a real user near your system while doing a benchmark, either. :-)
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.
The right way to turn off automatic snapshots completely for a volume is to use "snap sched [volname] 0", and, of course, delete any existing snapshots. "vol options [volname] nosnap on" is, to my mind, a temporary override to the normal schedule, for when you are doing something strange to the volume in question (like running a benchmark!).
The "snap reserve" has no effect at all on the taking of snapshots. It's to stop the active filing system using space "reserved" (in a rather curious sense) for the snapshots. Nothing stops the snapshots eating into the remaining space you might reasonably think of as designated for the active filing system. If you aren't going to have any snapshots, then certainly you should lower the reserve value, probably to zero, to let the a.f.s. use more.
Taking a snapshot can cause a momentary glitch in perfomance, and degrade the cache contents somewhat. If you are in a marginal situation, you might want to avoid scheduling automatic snapshots to coincide with extreme peak usage times. But in practice it's the *space* occupied by snapshots that drives nearly all decisions taken about using them, not the expense of taking them.
As you say, the options mentioned prevent only the taking of automatic snapshots. The "dump" command (run against the a.f.s.) will still take a snapshot, for example. You wouldn't want it not to.
1b. Would disabling these two options *prevent* me from `cd`ing into the .snapshot directory? Even though it is visible by default at the root of the mount point, you can `cd` into the directory ".snapshot" at any point:
"vol options [volname] nosnapdir on" is enough to make all .snapshot directories (both the previously "visible" and "invisible" ones) inaccessible (and invisible) to NFS (and presumably CIFS, etc.). On the other hand, if you have no actual snapshots, then every such .snapshot directory would appear empty anyway.
1c. In addition, I'm thinking of breaking up my 14-disk filer from a RAID 13d+1p configuration into, say, two RAID groups and two volumes as 3d+1p and 9d+1p. (Multiple RAID groups are allowed per volume; I assume multiple volumes per RAID group is still disallowed?) The former would have the stuff I need snapshotted and the latter the stuff I don't. I have a churn rate of about 30-40%. Thoughts?
If you've got material with *markedly* different snapshot requirements, then multiple volumes is the way to go. It costs in the extra parity discs, of course. (I notice you have no hot spares mentioned in your alternative configurations above, so I guess you are already somewhat desperate for space.)
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.