FsRtlCheckOplock简单描述

                                   FsRtlCheckOplock简单描述

  原文：http://www.osronline.com/article.cfm?article=223

   FsRtlCheckOplock这个历程目前（2003 IFS kit）还是没有文档化。因而，对于如何使用以及能做什么还不太清楚。本文将会试着去描述如何使用这个API。

   首先，我们假设你已经知道什么是oplock，如果你还不知道oplock，那么在接下来的讲述中可能就会觉得没有意思。

   而当正在执行的一些可能会使得一些客户端（oplock的持有者）的缓存信息无效函数时，由文件系统执行的一个很重要的函数支持检查oplocks的状态。非常典型的就是，本地oplock持有者是文件服务器，因此它会被看着是远程系统的代理而真正的拥有oplock。幸运的是，这些细节在文件系统运行库中被隐藏，并且大多数文件系统依赖于Windows去做这样的事。

       快速的看一下在windows server 2003 IFS kit中的FASTFAT源代码，会发现有9处使用了FsRtlCheckOplock:

   FatCommonCleanup:  如果这个文件持有了Level 1或者Level 2 oplock，那么必须在关闭这个这个文件的时候进行释放，因为客户端已不再使用这个文件了。注意Batch Oplock和Filter Oplock的意思是并不会在这个时刻去中断oplock。

   FatOpenExistingFcb:  这种情况我们就需要考虑是否有其他的客户端依然持有Oplock。当然正确性依赖于所给与的访问类型以及这个文件所持有的oplock。例如，如果存在一个客户端拥有了一个Level 1oplock在一个文件上，那么我们就不能允许访问这个文件，直到这个客户端已经将所修改的写回到原始文件中。通常，这种情况将会产生阻塞等待，但是有些时候(指定了FILE_COMPLETE_IF_OPLOCKED)这种可能会在oplock中断之前引起返回，表示STATUS_OPLOCK_BREAK_IN_PROGRESS。如果现在又一个客户端拥有了Level 2oplock，而如果当前调用者正在执行一个破坏性操作（FILE_OVERWRITE/FILE_SUPERSED）时，这个oplock可能需要被中断，相反将会被允许。当然，还有这里还有很多种不同情况：打开选项，已经给予的oplock类型，这个文件被打开的实例数目，以及是否调用正在请求一个过滤oplock。如果你没有在你的文件系统中使用这个历程，那么就必须为每一种情况进行表示。

FatCommonSetInformation( FileEndOfFileInformation / FileAllocationInformation)。在新的信息通知给远程客户端时，这是很清晰地一种情况，因为文件大小正在改变。因此，在客户端上的任何缓存信息很可能在这个时候会无效或不正确。

 FatSetRenameInfo：改文件名并不会对两种数据oplock（Level 1和Level 2）产生影响，但是oplock的两种属性(Batch 和Filter)会收到影响。因此，在更改文件名时中断batch oplock是很有必要的。

FatCommonRead:如果有一个来自拥有Level 1 oplock的远程客户端的读操作在一个文件上，那么远程客户端必须在返回数据之前将任意的数据缓存写回。注意Fat在是想上忽略了paging IO 操作which has some interesting ramifications。例如，文件内存映射在本地系统上，将会强迫中断那些oplock，所以本地客户端会读取不同的数据而不像远程客户端进行缓存。

FatCommonWrite: 如果文件被修改了（除了客户拥有了oplock），远程客户端进行缓存将不能工作，因而所有标准的oplock必须被中断。远程客户端需要丢弃它们所缓存的信息，并进行刷新缓存。

中断oplock 实际上会消耗一点的时间，这回使得将oplock包提交给原始的请求，因此在oplock完全中断之后才会处理。

这个包提供了两个钩子。在IRP被提交以及提交的IRP的oplock被完全中断时，在文件系统驱动中使用来获得进一步检查。这些都是可选的。

Oplock 包会调用优先调用OPLOCK_FS_PREPOST_IRP历程，而不是将原始的操作（文件系统传递给FsRtlCheckOplock的操作）进队。文件系统在在这里没有机会去修改事件的流程-Oplock 包仅仅通知文件系统有个给定的IRP已经提交。

Oplock包会在中断Oplock处理之后去调用OPLOCK_WAIT_COMPLETE_ROUTE历程。如果文件系统提供了这个历程，那么IRP将会带有额外的处理返回给文件系统。如果文件系统没有提供这个历程，那么这个IRP将会被oplock 包完成。因此，如果文件系统没有必要在oplock 被中断之后去处理额外的操作，这个历程也没有必要被指定。

多数文件系统提供oplock将会依赖于文件系统运行时哭是否实现了这样的功能。We will leave it to another time (and another article) to attempt explaining the details for those who wish to implement this themselves.

 

翻译不对之处，尽情之处！