Buffering State Control

RDBSS provides a buffering manager, a mechanism for providing distributed cache coherency in conjunction with the various network mini-redirectors. This service is encapsulated in the buffering manager in RDBSS that processes requests to change the buffering state. The buffering manager in RDBSS tracks and initiates actions on all change buffering state requests generated by the various network mini redirectors as well as by RDBSS.

There are several common components in the implementation of cache coherency in a typical network mini-redirector:

• Modifications to create and open file routines.

  In this path, the type of buffering request is determined and the appropriate request is made to the server. On return from the network mini-redirector, and possibly the server, the buffering state associated with the FCB is updated based on the result of the create or open call.

• Modifications to receive an indication code to handle change buffering state notifications from the server.

  If such a request is detected, then the local mechanism to coordinate the buffering states must be triggered.

• A mechanism for changing the buffering state that is implemented as part of RDBSS. Any change buffering state request must identify the SRV_OPEN structure to which the request applies.

The amount of computational effort involved in identifying the SRV_OPEN structure depends upon the protocol and details of the network mini-redirector. In the SMB protocol, opportunistic locks (oplocks) provide the necessary infrastructure for cache coherency. In the SMB protocol implementation in Windows, the multiplex ID APIs provided by RDBSS are used. The server gets to pick the multiplex ID used for identifying a file opened at the server. The multiplex IDs are relative to the NET_ROOT (share) on which they are opened. Thus, every change buffering state request is identified by two keys: the NetRootKey and the SrvOpenKey, which need to be translated to the appropriate NET_ROOT and SRV_OPEN structure, respectively. To provide better integration with the resource acquisition/release mechanism and to avoid duplication of this effort in the various network mini redirectors, the RDBSS provides this service.

There are two routines provided in RDBSS for indicating buffering state changes to SRV_OPEN structures:

• RxIndicateChangeOfBufferingState for registering the request

• RxIndicateChangeOfBufferingStateForSrvOpen for associating a SRV_OPEN structure with the key

Note that the key associations are irreversible and will last the lifetime of the associated SRV_OPEN structure.

Network mini-redirectors that need an auxiliary mechanism for establishing the mapping from multiplex IDs to the SRV_OPEN structure can use RxIndicateChangeOfBufferingState, while the network mini-redirectors that do not require this assistance can use RxIndicateChangeOfBufferingStateForSrvOpen.

The buffering manager in RDBSS processes these requests in different stages. It maintains the requests received from the various underlying network mini-redirectors in one of several lists.

• The Dispatcher list contains all of the requests for which the appropriate mapping to a SRV_OPEN structure has not been established.

• The Handler list contains all of the requests for which the appropriate mapping has been established, but has not yet been processed.

• The LastChanceHandlerList contains all of the requests for which the initial processing was unsuccessful. This typically happens when the FCB was acquired in a shared mode at the time the change buffering state request was received. In such cases, the oplock break request can only be processed by a delayed worker thread.

The change buffering state request processing in a network mini-redirector driver is intertwined with the FCB acquisition and release protocol. This helps to ensure shorter turnaround times.

RDBSS provides the following routines to manage buffering state that can be used by network mini-redirector drivers: