OSRLogoOSRLogoOSRLogo x OSR Custom Development Services

Everything Windows Driver Development

GoToHomePage xLoginx

    Thu, 14 Mar 2019     118020 members


  Online Dump Analyzer
OSR Dev Blog
The NT Insider
The Basics
File Systems
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Caching in Network File Systems

Typically, it is possible (and quite easy) for a file system filter driver to determine the caching policy of a local file system such as NTFS or FAT by simply examining the state of the I/O Request Packet (IRP).  The IRP_NOCACHE bit in the Flags field will tell the file system (and, of course, the filter) that the file I/O in question is not to be cached.  Normally, this is the clue to the file system driver that this data should not be cached.

Network file systems are a bit more complex than this.  While they also use the IRP_NOCACHE bit, they may also need to disable caching as a result of their own internal policy - perhaps directed by the state of the remote file on the file server, as well as other clients in the network that might be using the file.  The rdbss.sys, which implements part of the "mini redirector" model allows the redirector (for example mrxsmb.sys, which is the driver that implements CIFS or LanManager functionality in Windows 2000 and more recent) to change the caching policy on a per-file basis.  In this case, a normal IRP_MJ_READ IRP, which would normally be cached, may be treated as non-cached.

For a filter driver that is modifying the data, the usual technique is to look for and operate on non-cached I/O operations.  This will capture both paging I/O operations as well as user level non-cached I/O operations.  However, if the filter wishes to also filter any of the mini-redirectors (there are two shipped in Windows XP for example) it needs to look at the fields of the File Control Block (FCB).

For most file systems, the format of this structure is mostly under the control of the file system (except for the common header structure) but for mini-redirectors the format of the file control block is defined by the mini-redirector model.  See mrxfcb.h in the IFS Kit for the full definition.  The key data structure here (for a filter) is the MRX_FCB.  The FcbState field will indicate if the current state of the file is cached or non-cached.  If the file allows caching the FCB_STATE_READCACHING_ENABLED bit will be set.  Otherwise, I/O to the given file will be treated as non-cached.

Note: In the Windows Server 2003 IFS Kit the spelling of this flag has been changed so that it is now FCB_STATE_READCACHING_ENABLED

While this allows a filter to determine the current state of the file, there does not appear to be any simple way for a filter to ensure that the state of this field does not change between the time the filter checks it and the time the call is actually processed by the file system.  Thus, it is possible that the file state might change to disallow caching after this check is made.  Similarly, if the check is done after the I/O has been processed, it is possible the file state might change to indicate that caching is now allowed once again.  Sample code for this can be seen in the IFS Kit (see smbmrx\wnet\sys\openclos.c) to demonstrate one potential implementation model.

To prevent the state from changing, the caller must acquire the FCB resource; in order to avoid deadlocks while calling the redirector, it must be owned exclusive (using the ERESOURCE in the FCB itself).  Again, to do this requies relying upon the implementation and published interface available in the IFS Kit.

Note: this synchronization is only needed for user level cached requests, since paging I/O or user level non-cached requests will already not be cached as a matter of course.  This is important because this lock cannot be safely acquired when processing paging I/O - this would violate the existing lock hierarchy and introduce the possibility of deadlocks.

Related Articles
Are You Being SRVed? - The Lan Manager File Server on NT
Multi-Version Functionality
Caching in the Pentium 4 Processor
File System Filter Context - Observations and Comments

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"Generally Not Recommended"
The technique described in this article relies upon the specific format/layout of data structures. At the time it was published, the interface for this data structure for mini-redirectors was exposed and fixed, but even at that point it was not guaranteed that these data structures were used for all redirectors - but the real goal was to make this "work" with RDR2 and there really is no other mechanism for determining if a given file will be cached or not.

Since that time, Microsoft has changed the implementation of the CIFS redirector client so that this data structure is no longer used. Thus, you cannot use this technique in Windows Vista because the format of these structures is no longer the same. The new format is not published. There is no longer any mechanism for obtaining this information. In addition, filters frequently are now attached to MUP and not to the CIFS redirector, further complicating this process.

My suggestion is that if you wish to force write-through behavior that you take out a byte range lock. This will force the cancellation of oplocks and thus require that writes go back "through to the server". Naturally, this only applies for CIFS and not for other redirectors and like all behavior-based mechanisms is subject to change in the future.

09-Oct-07, Tony Mason

There is a spello with the flag "FCB_STATE_READCACHING_ENABLED", obviously its a negligible issue but better if corrected.

14-Nov-04, Rakesh Iyer

Post Your Comments.
Print this article.
Email this article.
bottom nav links