I'm afraid I don't know of a way to turn those messages off, other than to turn oplocks off, which is a rather drastic solution. Someone else at
NetApp
may know a way,
And sure enough, one of my learned colleagues reminded me of an option that may help here. My apologies. I need to go back on the ginseng supplements.
It turned out that this particular issue is actually aggrevated by filer based storage being too fast! While the issue does exist in native NT server environments, we discovered that the race condition that exists in various Windows client redirectors is tickled more frequently by filer based storage, simply because our response times are so much swifter (now there's gratitude for you! :-)). So.... we have a brake.
There is a "cifs.oplocks.opendelta" option, which is set to a default of 8 milliseconds. You can increase this value to put a brake on the filer-initiated oplock protocol transactions that occur at file open time, thus giving the client more time to breath and do the right thing. It has to write out the oplock break response, put it into an envelope, lick the stamp, etc.... Try increasing this option to 16 and the messages may either go away entirely or be reduced in frequency. You can also try higher values, although you don't want to crank this up to "silly" values or you may notice a reduction in perfromance. Note that this value only normally effects the performance of file open requests from clients. It doesn't effect any other performance area (raw throughput, response time of all the other operations, etc, etc..).
So, with a little manual adjustment, you may be able to tune this message away. As ever, we are striving to make your life easier and easier, so watch for this value to become heuristicly tuned on a per client basis in future versions of the microkernel.
Keith