Export (0) Print
Expand All

Granting Oplocks

Windows Server 2003

Oplocks are requested via FSCTRLs. Following are the FSCTRLs for the different oplock types:

  • FSCTL_REQUEST_OPLOCK_LEVEL_1
  • FSCTL_REQUEST_OPLOCK_LEVEL_2
  • FSCTL_REQUEST_BATCH_OPLOCK
  • FSCTL_REQUEST_FILTER_OPLOCK

When a request is made for an oplock and the oplock can be granted the file system returns STATUS_PENDING. The requesting oplock IRP does not complete until the oplock is broken. If the oplock cannot be granted an appropriate error code is returned. The most common returned error codes are STATUS_OPLOCK_NOT_GRANTED and STATUS_INVALID_PARAMETER.

The following table describes the rules for when an oplock can be granted:

Request:

Granted If:

Level 1 (exclusive)

Filter (exclusive)

Batch (exclusive)

  • The request is for a given stream of a FILE

    • If a directory, STATUS_INVALID_PARAMETER is returned
  • The stream is opened for ASYNCHRONOUS access

    • If opened for SYNCHRONOUS access STATUS_OPLOCK_NOT_GRANTED is returned
  • There are no TxF transactions on the file

    • Else STATUS_OPLOCK_NOT_GRANTED is returned
  • There are no other opens on the stream (even by the same thread)

    • Else STATUS_OPLOCK_NOT_GRANTED is returned
  • If the current oplock state is:

    • No Oplock – Request is granted
    • Level 1 - STATUS_OPLOCK_NOT_GRANTED returned
    • Level 2 – The original Level 2 request is broken with FILE_OPLOCK_BROKEN_TO_NONE. The Level 1 oplock is then granted
    • BatchOplock – STATUS_OPLOCK_NOT_GRANTED returned
    • FilterOplock – STATUS_OPLOCK_NOT_GRANTED returned

Level 2 (shared)

  • The request is for a given stream of a FILE

    • If a directory, STATUS_INVALID_PARAMETER is returned
  • The stream is opened for ASYNCHRONOUS access

    • If opened for SYNCHRONOUS access STATUS_OPLOCK_NOT_GRANTED is returned
  • There are no TxF transactions on the file

    • Else STATUS_OPLOCK_NOT_GRANTED is returned
  • There are no current Byte Range Locks on the stream

    • Else STATUS_OPLOCK_NOT_GRANTED is returned
    • Note that the current implementation in windows checks to see if there has ever been any byte range locks on the stream and fails the request if yes. The plan is to address this in the future to fail only if there are active byte range locks on the stream.
  • If the current oplock state is:

    • No Oplock – Request is granted
    • Level 1 – STATUS_OPLOCK_NOT_GRANTED returned
    • Level 2 – Request is granted. You can have multiple Level 2 oplocks granted to the same stream at the same time.
    • BatchOplock – STATUS_OPLOCK_NOT_GRANTED returned
    • FilterOplock – STATUS_OPLOCK_NOT_GRANTED returned

There is one other scenario where an oplock request can be made. On an IRP_MJ_CREATE the caller can specify the FILE_RESERVE_OPFILTER flag in the create options. This flag indicates that the caller wants an exclusive oplock for this stream. The oplock is not granted at create time but the OPLOCK_PENDING state is set internally such that an exclusive oplock request is expected. The caller can then request a Level 1, Batch, or Filter oplock on the given stream. If a Level 2 request is made it will be failed with STATUS_OPLOCK_NOT_GRANTED.

Below is a table which describes the rules for the create request to be successful.

Request:

Create successful if:

Request for a Filter oplock while processing IRP_MJ_CREATE

  • The request is for a given stream of a FILE

    • If a directory, STATUS_INVALID_PARAMETER is returned
  • The stream is not already open

    • Else STATUS_OPLOCK_NOT_GRANTED is returned
  • The desired access is exactly FILE_READ_ATTRIBUTES access

    • Any other access (including SYNCHRONIZE) will cause STATUS_OPLOCK_NOT_GRANTED to be returned
    • This implies the stream must be opened for asynchronous access
  • The following share access modes must be specified:

    • FILE_SHARE_READ
    • FILE_SHARE_WRITE
    • FILE_SHARE_DELETE
  • Since this is an open request and there can be no previous opens on the stream there is no existing oplock state that must be checked

In the current implementation of this feature there is a window between the time the check is made to see if this is the only open on the stream and the oplock request being granted. During this window another caller can open the stream and the oplock will not be broken.

Show:
© 2014 Microsoft