1. We just started to run 5.3.5 on one of our 740s in order to test compatibility with Windows 2000. Is anyone else doing this successfully?
2. With 5.3.5 we are getting lots of messages on the console like:
GMT [CIFSAdmin]: oplock break timed out to station CST209 for file \NTCR2\w95apps\APPLICATIONS\SPSS\9\spssprod.inf
We support some 1200 Windows 95 PCs, and at peak times we get several messages per minute for different files and PCs. Does anyone know what this means, should we care about it, and if not, can we turn them off!
3. Finally, I still don't think NetApp have quite got their early access releases sorted out properly. I looked at the NOW site and downloaded 5.3.5, but when I talked to a support engineer today he said "Why aren't you running 5.3.5P2?"
Dave Atkin
------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk ------------------------------------------------------
- Finally, I still don't think NetApp have quite got their early access
releases sorted out properly. I looked at the NOW site and downloaded 5.3.5, but when I talked to a support engineer today he said "Why aren't you running 5.3.5P2?"
Advice learned the hard way: don't upgrade your netapp box without first talking to netapp support about which particular version to upgrade to.
Nick
- With 5.3.5 we are getting lots of messages on the console like:
GMT [CIFSAdmin]: oplock break timed out to station CST209 for file \NTCR2\w95apps\APPLICATIONS\SPSS\9\spssprod.inf
We support some 1200 Windows 95 PCs, and at peak times we get several messages per minute for different files and PCs. Does anyone know what this means, should we care about it, and if not, can we turn them off!
Hmmm. We've started printing those out have we? I see...
To understand what they are, you first need an understanding of opportunistic locks (oplocks) generally. The clearest description of them that I've uncovered lies in a Microsoft Systems Journal artical which you will find at:
http://www.microsoft.com/MSJ/0100/win32/win320100.asp
If you're not interested enough to read the whole thing, and most people probably aren't, the sections on level 1 and level 2 oplocks should suffice.
So what's with this message? Very simply, some versions of Windows do not reliably respond to oplock break requests. Windows 95 is especially bad, and on a big network it is not entirely surprising that you are seeing quite a few of these. If it's any comfort, this has almost certainly been happening on your network all along, it's just that we're now bringing it to your attention with a message on the console. Perhaps we should have left you blissfully unaware? :-)
In actuality, the non-responsive oplock break "problem" is rarely serious, although it can leave the server end of a CIFS connection with a dilemna on its hands. You'd have to worry about it more if you were using cooperative flat file database applications like Access, FoxBase, DBase and so forth. For these, it is recommended that you turn oplocks off entirely (they don't add any value when cooperative file sharing is the rule rather than the exception). Judging from the message you quoted above, it looks like you just have a multiple-reader type scenario, so non-responsive oplock break requests shouldn't be that big of a deal.
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, or if I find out internally here I'll e-mail you privately.
Keith
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
-
Dave Atkin -
Keith Brown -
Nick Hilliard