A couple of things:
1. cifs_latency is a counter that you will find associated with each individual volume in DFM. You can type "dfm perf data retrieve -o your_filer -C cifs:cifs_latency -d 3600" and this will show you cifs_latency value of every volume for the past hour(3600 seconds). You can play with what comes after -o and narrow it down to just one volume/aggr/whatever, and you can specify the window with -b/-e switch. Type dfm perf data retrieve help for more information.
2. The volume with highest cifs_latency may not be the offender. It probably is the one that experienced the biggest pain, but it may not have caused the issue.
3. In our environment(I'm a NetApp customer), it is very helpful to distinguish between cifs_latency and storage latency(volume:avg_latency, read_latency, write_latency). This is because it is possible, and is often the norm in our environment, that when there is high cifs_latency and low volume-level latency, the issue exists somewhere beyond the filer. This could be your AV scanner, or AD, or something else. High cifs_latency is often not a filer performance issue in our environment.
4. If the issue is something you can predictably capture, I recommend engaging NetApp support to begin data collection. They can tell you all of this in more detail, and also look at additional data their perfstat tool will collect that DFM doesn't.
