缓存之网络文件系统

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.

Remember read this article before and tried it myself. It doesn't work as expected.

原文地址：http://www.osronline.com/article.cfm?article=226