網路檔案系統的cache機制

Caching in Network File Systems
OSR Staff | Published: 09-May-03| Modified: 09-May-03
網路檔案系統的cache機制

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.
對於檔案系統過濾驅動程式來說，確定本地檔案系統NTFS或者FAT的cache策略是相當容易的，只要檢查一下I/O請求包（IRP）的狀態就可以了。如果發現IRP的flag域帶有IRP_NOCACHE標誌，就說明檔案系統不允許檔案cache。

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 s
erver, 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 Lan
Manager 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.
而網路檔案系統在cache策略方面則有點複雜。雖然它們也使用IPR_NOCACHE標誌，它們也需要在它們的內部策略當中禁止使用檔案cache，這些內部的cache策略是由檔案伺服器上的遠程檔案的狀態決定的，而網路上其它的用戶端都會使用這些檔案。rdbss.sys驅動程式實現了被稱為“mini redirector”模型的一部分功能，它能夠允許每一個重新導向器（redirector）基於每一個檔案來改變其緩衝策略。在這種情況下，一個普通的IRP_MJ_READ類型的IRP可能被當作可被緩衝的，也可以被當作非緩衝來處理。

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).
對於一個正在修改檔案讀資料的過濾驅動程式來說（例如對檔案內容做透明加解密的驅動程式），通常是通過檢查和攔截非緩衝I/O請求來實現自己的功能。這樣它們就會捕獲分頁I/O操作或者使用者層的非緩衝I/O操作。但是，如果過濾驅動程式如果也想攔截mini-redirector的話，它就必須檢查檔案控制區（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 mode
l.  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.
對於大多數檔案系統來說，FCB結構的格式主要由檔案系統來決定，除了通用的頭結構以外，但是mini-redirector的FCB結構的格式由mini-redirector模式定義，完整的FCB定義可以參考mrxfcb.h。對過濾驅動程式來說，最關鍵的資料結構是MRX_FCB。該結構的FcbState域描述了該檔案是否需要cache或者非cache。如果檔案可以被cache，則FCB_STATE_READCACHING_ENABLED標誌將置位。否則，對於指定的檔案將被視為非cached。值得注意的是在Windows Server 2003 IFS Kit中，這個標誌的拼字已經發生了變化，現在的拼字是FCB_STATE_READCACHING_ENABLED。

Note: In the Windows Server 2003 IFS Kit the spelling of this flag has been chan
ged 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 cal
l 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 stat
e 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.
通過檢查FCB結構的FcbStatus域的狀態，允許過濾驅動程式檢查當前檔案的狀態，但是卻沒有什麼有效而簡單的方法確保過濾驅動程式檢查時的狀態與檔案系統真正處理這個檔案之間該檔案狀態保持不變。因此這樣的情況很可能發生－檔案過濾驅動程式檢查檔案狀態時，檔案是允許cache的，但是真正處理的時候變為不允許cache了。相反的情況也同樣會出現。詳細的樣本請看IFS的例子代碼（smbmrx/wnet/sys/openclos.c）。

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 u
pon the implementation and published interface available in the IFS Kit.
為了防止這種狀態的變化，調用者必須擷取FCB的資源。為了避免調用redirector其間出現死結現象，調用者必須排他的擁有FCB資源。

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.

Eventually I figured out this was because network redirectors like to set an internal flag called SRVOPEN_FLAG_DONTUSE_WRITE_CACHEING when a file is opened for write-only, which causes the redirector to send all writes across the network as soon as it gets them, bypass the NT cache. This means any layered filter will see the ordinary write request, but never a corresponding paging-I/O request. To get around this, my filter now has to forcibly turn every write-only network file open into aread/write open.
當一個檔案以唯寫（write-only）方式開啟時，網路重新導向器會設定一個內部標誌－SRVOPEN_FLAG_DONTUSE_WRITE_CACHEING，這將導致重新導向器發送所有的寫請求到網路檔案伺服器上，繞過了NT cache機制。這意味著所有的分層過濾驅動程式只能看到普通的寫請求，但是不會看到任何對應的分頁I/O請求。為了能夠過濾網路檔案的讀寫分頁請求，我的過濾驅動程式不得不強迫將所有的以唯寫（write-only）方式開啟網路檔案變為讀寫方式開啟。

下面是如何將write-only開啟的檔案轉換為讀寫開啟的檔案的方式：
The reason why I'm ranting in public is that seems that I can never know a-priori whether I will see a read or write request as both paging and non-paging I/O, or one or the other, for a given filesystem. Instead, I must special case my code for each filesystem and pray that I've covered every scenario that can result in my not handling a read/write or
handling it twice. The only alternative I can come up with is to force ALL reads/writes to a filtered file to be non-cached, with the corresponding performance penalties. Is there an elegant way out of this mess?

I think I sent a message about this before. The long and the short of it is that you CANNOT force the redirector to cache writes for files that are open write-only. You must instead tweak the file permissions to 'convert' a write-only open of a network file into a read/write open. Use code like the following to do so:

if ((0 == (desiredAccess & (FILE_EXECUTE |FILE_READ_DATA))) && (0 != (desiredAccess & (FILE_WRITE_DATA |
FILE_APPEND_DATA))))
{  
  pIrpSp->Parameters.Create.SecurityContext->DesiredAccess |= FILE_READ_DATA;
}

下面解釋了為什麼write-only類型的檔案不能執行cache
write only handle in redirector doesn't cache

--------------------------------------------------------------------------------

I got bitten by this a few months ago, so here is my take on the situation...

This is because the NT cache needs read access to the file in order to work. The cache works on page-sized chunks. If you open a file and write 1 byte at location 0, and caching is enabled, the NT cache will page-in the memory page representing the first 4096 bytes of the file, which requires it to issue a paging I/O read for the first 4096 bytes. Then it will paste in your new byte and mark the page dirty, which causes the page to be written out later by the lazy writer.

For local files, paging I/O is allowed to bypass all security checks (since only trusted kernel components can issue paging I/O requests), so that paging reads are allowed on all opens for all files. For network files, there is no reason the remote PC should 'trust' your PC and grant it read access if you only have write-access to the file. Therefore the NT cache cannot be used on write-only remote files.