Opportunistic Locking

In the SMB protocol, Opportunistic Locking (also referred to as OpLocks) is a file locking mechanism designed to improve performance by controlling caching of files on the client. Contrary to traditional locking, OpLocks are not used in order to provide mutual exclusion, rather the main goal of OpLocks is to provide synchronization for caching.

Locking types

In the SMB protocol there are 3 types of Opportunistic Locks:

Batch Locks

Batch OpLocks were created originally to support a particular behavior of MS-DOS batch file execution operation in which the file is opened and closed many times in a short period. This is an obvious performance problem. To solve this, a client may ask for a Batch type OpLock. In this case, the client delays sending the close request and if a subsequent open request is given, the two requests cancel each other.

Exclusive Locks

When a client opens a file hosted on an SMB server which is not opened by any other process (or other clients) the client receives an Exclusive OpLock from the server. This means that the client may now assume that it is the only process with access to this particular file, and the client may now cache all changes to the file before committing it to the server. This is an obvious performance boost, since fewer round-trips are required in order to read and write to the file.If another client/process tries to open the same file, the server sends a message to the client (called a break or revocation) which invalidates the exclusive lock previously given to the client. The client then flushes all changes to the file.

Level 2 OpLocks

If a file is opened by a third party while an Exclusive OpLock is held by a client, the client has to relinquish its exclusive OpLock to allow the other client's write/read access. A client may then receive a "Level 2 OpLock" from the server. A Level 2 OpLock allows the caching of read requests but excludes write caching.

Breaks

In contrast with the SMB protocol's "standard", a break request may be sent from "server" to client to inform the client that an OpLock is no longer valid. This happens, for example, when another client wishes to open a file in a way that invalidates the OpLock. The first client is then sent an OpLock break and required to send all its local changes (in case of batch or exclusive OpLocks) if any and acknowledge the OpLock break. Upon this acknowledgment the server can reply to the second client in a consistent manner.

ee also

* Optimistic concurrency control