|
NOTE
OpLocking is a Microsoft invention. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/opportunistic_locks.asp for more information. (This link is provided as a courtesy. Novell is not responsible for, and does not endorse in any way, the content of external internet sites.)
This TID discusses Novell's implementation of Opportunistic Locking.
What are OpLocks? What is Opportunistic Locking?
Opportunistic Locking is a method of caching server data locally on the client. This can result in significant performance improvements.
Level I OpLocking allows a single client to effectively read in an entire file, keep a copy on the workstation and lock the version on the server.
Level II OpLocking allows multiple clients to read in the same file, keep a copy on the workstation and share the version on the server.
OpLocks should not be confused with any of the following:
- File Locks: lock the file on the server but don't cache it locally
- Record Locks: as used by back-end database applications
- Byte range Locks: also used by back-end database applications; client requests to lock 128 bytes at offset A1000, etc
How is it possible to tell if a database is using record or byte locks? The only reliable way is to trace it.
What are the Pros and Cons of Opportunistic Locking?
- No OpLocking
Reliable
Slow - does small reads (small reads are the lowest common denominator - if the application isn't optimised to request request big reads then the client will go with the safe option rather than negotiate a large read).
- Level I
Fast - does big bursty reads
Caches file locally and puts an exclusive lock on the server version
Can cause slowness
Can cause server hangs
- Level II
Fast
Caches file locally but lets other clients cache locally, too
Can cause Database corruption
Can cause failure to save
Further Information on Opportunistic Locking
OpLocking is more complicated than it initially seems. This section summarises what is going on behind the scenes.
If Client1 holds an OpLock I and then Client2 wants the file, the server will BROADCAST a request to clear OpLocks so that Client2 can obtain the lock.
Client1 then has to ACK this broadcast. Once it has done that, it can choose whether to close the file (so that Client2 can have it) or switch to Level II OpLocking (so that they both can have it).
Here lies a potential problem: Client1 has to ACK the server's broadcast. If Client1 does not ACK then Client2 is going to wait. Consider what could happen if Client1 and Client2 are on separate subnets or VLANS or if Client1 sits on a flaky network. This is not a bug in Novell's implementation - this is a problem inherent in the design of OpLocking.
Now consider how this issue would be traced. What benefit is a trace of Client2, where we only see the symptoms? This problem must be traced at the server.
A Level II OpLock allows multiple clients all to cache a copy of a file locally. This can be very effective as long as the client is only reading a file.
When a client wants to do a write, the system operates on a first-come first-served basis. When this happens the server does a broadcast and expects all the clients to ACK it, but it won't wait, and will grant the writer exclusive access and assume that everyone else will clear their cache and get the new just-written version.
Therefore, if Writer2 doesn't see the initial broadcast then the save may fail or, if a database application is involved, the database could become corrupt (as the data is never successfully written).
Problems with applications that use temp files (e.g. Word, Excel etc)
With applications that use temp files, the sequence of events should be:
1 Client Opens Original > 2 Client Creates Temp (copy of original) > 3 Client Modifies Temp > 4 Client Saves Temp > 5 Client Deletes Original > 6 Client Renames Temp to Original's Name
Then we go back to Step 2, etc, without having closed the file.
Some versions of the client occasionally miss out Step 5. Obviously this causes problems, as Step 6 (and thus the save) will fail. This may also generate the console error "Station xx (task X) timed out waiting for an op-lock on file xxxxxxxx.xxx held by station xx"
This is fixed in Novell Client 4.9 SP2 + the latest 4.9 Post-SP2 NWFS.SYS (49psp2_nwfs_8.exe) and later.
OpLocking and NCPs
The Novell client implements OpLocking through NCP (87,32). Originally when the Novell client needed to open a file it would issue an NCP 87,01 (Open/Create file or subdirectory). Novell modified the 87,01 NCP to include a flag (OCCRetFlag) to request an op-lock. The new NCP 87,32 (Open/Create file or subdirectory with Callback) utilises the same structure as NCP 87,01 but also includes this new flag. When clients are configured to support OpLocking/File Caching then open requests are performed with the 87,32 NCP.
Summary
- When troubleshooting poor performance, turn OpLocking ON as a diagnostic
- When troubleshooting file open/save problems, turn OpLocking OFF as a diagnostic
- Take traces at the server and do not filter traces (OpLocking uses broadcasts and then expects ACKs from other clients, so just trace everything and filter within the trace analyzer)
- There are problems with applications that use temporary files, so look for file renames and file deletes in traces, especially those that result in an error
- A lack of response to a broadcast can cause issues so look for broadcasts - the server will broadcast a Clear Callback and the client should ACK Callback
- Failure to ACK the Clear OpLock Broadcast is an issue inherent in the technology
- Level II OpLocks are inappropriate for database applications: don't use OpLock Level II with databases (Level I OpLocks can remain switched on, however)
OpLocking issues with older versions of NSS and Novell Client are well documented. As of NW6SP5/NW65SP2 and Client 4.9SP2 there are no outstanding issues with OpLocking reported to Novell other than the Temp file issue, mentioned above.
Further resources
These links are provided as a courtesy. Novell is not responsible for, and does not endorse in any way, the content of external internet sites.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/opportunistic_locks.asp - Microsoft MSDN article
http://support.microsoft.com/default.aspx?scid=kb;en-us;129202 - Microsoft QID article
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html - 3rd Party White Paper
http://www.superbase.com/services_tech_support_oplocks.htm - 3rd Party paper on Opportunistic Locking in a pure Windows environment
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10085899.htm - Further information on Novell's implementation of OpLocking
|
