OpLocks on NetWare

From MicroFocusInternationalWiki
Jump to: navigation, search

OpLocks, or "opportunistic locking," has been a feature with NetWare for quite some time. And for quite some time it hasn't worked all that well. This is begining to change (as of March 2006), but time has not changed the conventional wisdom on this topic. This article attempts to shed light on what the generally accepted settings are, what the settings mean, and how it impacts operations.

Summary Recommendations

Current Recommendation

On the Server:

SET LEVEL 2 OPLOCKS ENABLED = OFF
SET CLIENT FILE CACHING ENABLED = OFF

This disables OpLocks and client-side caching of files. This will work on all client versions.

When OpLocks work

With NetWare 6.5 SP4a and newer, AND, Windows Client 4.91sp2 and newer, OpLocks may work correctly. This configuration hasn't been out long enough for us to be sure of it, but it looks better than it was.

Details of How It All Works

OpLocks Explained

Novell has put out a couple of TIDs that explain things.

TID10071902: File Caching and Opportunistic Locking

TID10085899: OpLock, Opportunistic locking (Level I & II) Client File Caching.

The more detailed explanation is in 10071902. The details in this section are drawn heavily from this document.

Level 1 OpLocks

Level 1 OpLocks have been around for some time. In this mode, a Client locks a file that it intends to use, the Client then downloads the whole file into Workstation memory where the Application works on it. This is done through "NWFS.SYS" in the Client. When the Workstation is done with it, the file is flushed back to the server, and the lock is cleared. Doing it this way allows much faster application performance, but it does not permit shared-files such as Access databases to be multi-user.

Level 2 OpLocks

These OpLocks work the same as Level 1 OpLocks, but second workstations are permitted to access the file in R/O mode. The advantage to Level 2 OpLocks is that it discriminates between Read-locks and Write-locks, where Level 1 does not.

Why OpLocks are a good idea

By moving the file being worked on into the client's memory, the application then works on what is in essence a local copy. This means that all the file-accesses happen locally rather than across the network to the file-server. On slower networks this can be a very good thing.

A real-world example:

"I had to troubleshoot an application that had very slow load times. This was a database-like application that was used for tracking of various tasks. End users in the field were reporting that it was taking up to four minutes for the application to fully load to a usable state. This needed to be fixed, since this application was critical to business function.

After much looking around, I noticed a very curious detail. In MONITOR I watched the user's connection-stats as they opened the application. The "Requests:" were going up very fast, and so was the "Kilobytes Read:". I had the user do it a second time, but this time I recorded the values in both fields before they opened the application. Comparing the before and after numbers I learned that the application was making requests sized about 256 bytes, and this was done over a network with at least one 10base2 segment.

The files the application were opening were large, so it wasn't that it was hitting a lot of individual files. The application was requesting sub-ranges within the specific files. Due to network latencies (that 10base2 segment) the application's network behavior was causing the slowness. In this case, the problem was fixed by eliminating the 10base2 segment and eliminating a second media-translation.

If OpLocks were in use in this case, the first Open request would cause the entire file to download in one piece to the client, and load-time would be very fast. OpLocks would have enabled this application that does not behave well over high-latency links to function much better."

OpLock Scenarios

What happens: Two workstations request access to a single file (level 1)

  1. The first workstation opens the file, and it is granted the OpLock.
  2. The second workstation attempts to open the file.
  3. The server informs the first workstation to clear its lock.
  4. The first workstation flushes the file from memory to the server.
  5. The server clears the oplock.
  6. The server tells both workstations that access is granted, but neither have a lock.

What happens: First workstation requests R/W, second requests, R/O (level 2)

  1. The first workstation opens the file, and it is granted the OpLock.
  2. The second workstation attempts to open the file, requesting Read-Only.
  3. The server grants the R/O OpLock.
  4. The first workstation maintains its R/W lock. When it is done with the file, it will close it and flush the changes back to the server.

In this scenario, the second workstation gets the R/O lock and both workstations get a lock. In the previous scenario, once the second workstation attempted access, neither workstation had a lock but still had the file open.

What happens: First both workstations request R/W (level 2)

  1. The first workstation opens the file, and it is granted the OpLock.
  2. The second workstation attempts to open the file, requesting Read/Write.
  3. The server informs the first workstation to clear its lock.
  4. The first workstation flushes the file from memory to the server.
  5. The server clears the OpLock
  6. The server tells both workstations that access is granted, but neither have a lock.

This is functionally identical to the first scenario.

OpLock Failures

There are several ways that the OpLock mechanism can go bad.

  • If the workstation holding the R/W lock does not clear it as it should when requested, it can hold up all access to the file.
    • This is the prime cause of this kind of error-message:
      Station xxx ( task 1) has timed out on its op-lock ( type= 2) 
  • Memory corruption issues on the client can affect the cached versions of the file, which when flushed to the server will affect data integrity.
  • If the file is very large, caching locally can take quite some time.

Server Settings

SET LEVEL 2 OPLOCKS ENABLED

This turns on and off Level 2 OpLocks.

SET CLIENT FILE CACHING ENABLED

This turns on and off client-side caching, or Level 1 OpLocks.

Gotcha

To disable all OpLocks, set BOTH to OFF. A client can still hold a level 2 OpLock even if client file caching is turned off. It is unclear if this behavior is by design or an undocumented feature.

Client Settings

The client-side setting is located:

Advanced Settings -> Performance, Cache -> File Caching [On/Off]

This turns off Level 1 OpLocks. There is no way to turn off Level 2 OpLocks from the Client.