HP CIFS File Locking Interoperation

9
BYTE RANGE LOCKING is invoked programmatically – on a file that is already open - by
the Windows LockFile and LockFileEx APIs when a client application wants to lock a region
of a file for exclusive access.
LockFile parameters only specify the file name and byte ranges to be locked. Therefore the
lock must be exclusive – all other processes are denied access to the specified region of the
file. If the region cannot be locked, the API returns immediately – it does not block or wait.
LockFileEx includes a flags parameter that allows the process to wait for a locked region of a
file to unlock. It also includes a sharing option that allows another process to read the locked
region concurrently but denying write access concurrently.
Byte Range locks are honored unilaterally by Windows and Windows applications that call
LockFile and LockFileEx, so a process is guaranteed to have the particular access granted by
the API when the call succeeds.
OPPORTUNISTIC LOCKING (Oplocks) is invoked by the Windows file system (as opposed
to an API) via registry entries (on the server AND client) for the purpose of enhancing
network performance when accessing a file residing on a server. Performance is enhanced by
caching the file locally on the client which allows:
Read-ahead: The client reads the local copy of the file, eliminating network latency
Write caching: The client writes to the local copy of the file, eliminating network
latency
Lock caching: The client caches application locks locally, eliminating network
latency
The performance enhancement of oplocks is due to the opportunity of exclusive access to the
file, even if it is opened with deny-none, because Windows monitors the file’s status for
concurrent access from other processes.
Windows defines 4 kinds of Oplocks:
Level1 Oplock - The redirector sees that the file was opened with deny none (allowing
concurrent access), verifies that no other process is accessing the file, checks that oplocks are
enabled, then grants deny-all read-write exclusive access to the file. The client now performs
operations on the cached local file.
If a second process attempts to open the file, the open is deferred while the redirector
“breaks” the original Oplock. The Oplock break signals the caching client to write the local
file back to the server, flush the local locks, and discard read-ahead data. The break is then
complete, the deferred open is granted, and the multiple processes can enjoy concurrent file
access as dictated by mandatory or byte-range locking options. However, if the original
opening process opened the file with a share mode other than deny-none, then the second
process is granted limited or no access, despite the Oplock break.
Level2 Oplock – Performs like a level1 oplock, except caching is only operative for reads. All
other operations are performed on the server disk copy of the file.
Filter Oplock – Does not allow write or delete file access.
Batch Oplock – Manipulates file openings and closings.