Understanding oplocks

Write cache data loss considerations when using oplocks

Under some circumstances, if a process has an exclusive oplock on a file and a second process attempts to open the file, the first process must invalidate cached data and flush writes and locks. The client must then relinquish the oplock and access to the file. If there is a network failure during this flush, cached write data might be lost.

Data loss possibilities

Any application that has write-cached data can lose that data under the following set of circumstances:

It has an exclusive oplock on the file.
It is told to either break that oplock or close the file.
During the process of flushing the write cache, the network or target system generates an error.

Error handling and write completion

The cache itself does not have any error handling--the applications do. When the application makes a write to the cache, the write is always completed. If the cache, in turn, makes a write to the target system over a network, it must assume that the write is completed because if it does not, the data is lost.

When to turn oplocks off

CIFS oplocks on your storage system are on by default.

You might turn CIFS oplocks off under either of the following circumstances:

You are using a database application whose documentation recommends that oplocks be turned off.
The CIFS clients are on an unreliable network.
You are handling critical data and you cannot afford even the slightest data loss.

Otherwise, you can leave CIFS oplocks on.

How storage system oplock setting interacts with client oplock setting

You can turn CIFS oplocks on or off at individual clients using a Windows registry setting. Turning CIFS oplocks on at the storage system does not override any client-specific settings. Turning CIFS oplocks off at the storage system disables all oplocks to or from the storage system.