CIFS 下opportunistic locks（机会锁）

cifs协议File and Record的locking

1. 当文件locked的时候，non-locking的应用是无法访问文件的。
2. Safe caching, read-ahead, and write-behind
   cifs应该提供缓存，无论这个文件是不是加锁的，并使用读优先的方式。当只有一个client访问文件的时候，怎么操作文件都是安全的。当多个client通过读的方式访问一个文件的时候，其实也是安全的。若是多个client同时用写的方式访问一个文件呢？

If many clients are writing a file simultaneously, then none are safe,
and all file operations have to go to the server. The protocol
notifies all clients accessing a file of changes in the number and
access mode of clients accessing the file, so that they can use the
most optimized safe access method.
当多个client同时写一个文件的时候,没有谁的操作是安全的，所有的文件操作都必须发送给服务器。协议会把访问这个文件的行数和访问权限等信息发送给每一个访问这个文件的客户端，因此客户端们可以尽量采取安全的方式去访问。

3.CIFS中引入了一叫做opportunistic locks的锁，简称oplocks。
客户端可以锁定一个文件，但是这个锁可以随时被服务器撤消。
oplocks的目的是让客户端上的文件缓存更加安全。

When a client opens a file it may request an oplock on the file. If the oplock is given the client may safely perform caching. At some point in the future a second client may open the file. The following steps provide an overview of the actions taken in response to the open from the second client:
x The server holds off responding to the open from the second client.
x The server revokes the oplock of the first client.
x The first client flushes all cached data to the server.
x The first client acknowledges the revoke of the oplock.
x The server responds to the open from the second client.
As can be seen from the above steps, the first client has the opportunity to write back data and acquire record locks before the second client is allowed to examine the file. Because of this a
client that holds an oplock can aggressively cache file data and state.
Anecdotal evidence suggests that oplocks provide a performance boost in many real-world applications running on existing CIFS client implementations while preserving data integrity.

当一个客户端打开一个文件时可能会对其加锁，如果获得了锁可以保证客户端安全的操作缓存数据。在将来的一段时间后，可能第二个客户端也要打开这个文件。这是可能发生以下的步骤：
a,服务器收到了第二个客户端的请求。
b,服务器撤销了第一个客户端的锁。
c,第一个客户端向服务器刷新所有数据的缓存。
d,第一个客户端承认了锁被撤销.
e,服务器响应第二个客户端的打开请求，在第二个客户端检视文件之前，第一个客户端有机会写回数据以及申请记录锁。正因如此拥有oplock的客户端可以随意修改缓存文件的数据和状态。大量实例研究表明，oplock可以保证大量CIFS客户机应用程序的性能的同时保证了数据完整性。

oplock的类型

oplock一共有三种类型：

1.Exclusive
2.Batch
3.Level II
其中Level 2是在NTLM 0.12中引入的。
一、Exclusive和Batch
当一个客户端对一个文件拥有一个exclusive oplock的时候，它是唯一一个打开文件的客户端。

The exclusive oplock allows the client to safely perform file data
read and write caching, metadata caching, and record lock caching. All
other operations on the file cannot be safely cached.

服务器可能随时收回exclusive oplock，但是可以保证的是服务器会在另一个客户端成功打开文件之前收回这个锁。这就给了拥有exclusive oplock的客户端回写缓存数据的机会。
        batch oplock允许一个客户端在当这个文件被应用程序反复打开的时候推迟关闭文件。服务器保证一个客户端在拥有batch oplock的时候，一定是先收回锁再有其他客户端成功的改变文件。
   当一个客户端在打开一个文件的时候可以申请一个exclusive oplock或者batch oplock，或者不申请任何锁。这两种锁只能在打开文件的时候被获得，除此之外别无他法。
        oplock只能用在文件上，不能用于目录或者命名管道。不过对目录或者命名管道申请oplock的时候并不产生错误，在这种情况下服务器会回复没有为你授权任何锁。
        服务器对一个成功的打开命令的回复信息里会包含什么类型的oplock被授予了。一个不支持oplock的服务器应该永远回复没有授予任何oplock。
        一个客户端在申请exclusive oplock的时候会获得以下几种中的一个：

• 一个exclusive oplock
• 一个level 2 oplock

• 没有oplock

     一个客户端在生气batchoplock的时候会获得以下几种中的一个：

• 一个batch oplock

• 一个level 2 oplock

• 没有oplock

  The revoking of an exclusive or batch oplock involves the server sending an oplock break message to the client, followed by the client flushing file information to the server, followed by the client releasing the oplock. If the client does not respond by releasing the oplock within a period of time acceptable to the server, then the server may consider the oplock released and allow pending operations to proceed. The protocol does not define the duration of the time out period.

  　　服务器在有别的客户端访问文件时会向拥有锁的客户端发送一个oplock breaking，接着客户端回写了数据，然后客户端释放了oplock。如果在服务器的规定时间内客户端没有以释放锁的方式回应服务器的话，那么服务器会认为锁被释放了并且允许等待后续操作。但是协议并没有明确定义这个时间是多少。

When a client opens a file that already has an exclusive oplock, the
server first checks the share mode on the file. If the sharing allows
the client open to succeed then the exclusive oplock is broken, after which the open is allowed to proceed.

      当一个客户端打开一个已经有exclusive oplock的文件时，服务器首先检查文件的共享模式。如果共享允许客户端打开，那么锁在成功打开之后就会损坏。

When a client opens a file that already has a batch oplock, the server first revokes the batch oplock. Then the open is allowed to proceed. The reason for this server behavior is that it gives the holder of the oplock the opportunity to close the file. This in turn allows the open to obtain an exclusive or batch oplock.

当一个客户端打开一个已经有batch oplock的文件时，服务器首先会撤回batch oplock，然后这个打开才允许被进行。这种服务器行为的原因是它要给锁的拥有者关闭文件的机会。这反过来允许打开命令去获得一个exclusive或者batch oplock。

When a client opens a file that has a security descriptor, the server
first checks if the open for the desired access is allowed by the
security descriptor. If access is not allowed, the open fails. Any
exclusive or batch oplock on the file is not disturbed. Because of
this behavior a client holding an exclusive or batch oplock cannot
safely cache security descriptor information

二、Level 2 oplock
    当一个客户端对一个文件拥有二级锁的时候，意味着其他客户端也open着文件。这个二级锁允许客户端安全的执行读缓存，但是任何其他缓存的操作都不能被保证安全。
    服务器随时有可能撤回二级锁，但是服务器保证在其他客户端成功的写文件之前会先撤回二级锁。这给了拥有二级锁客户端丢弃缓存数据的机会。
    但是要注意的是在取消二级锁的时候和另外两种锁是不一样的。一个二级锁的break发送给客户端后，不期望客户端给出回复。服务器在发送了break之后会允许写操作立即进行。（另外两种锁则是要等待客户端的release回应）
    客户端并不能直接明确要求加二级锁。服务器在打开文件或者撤回另外两种锁的时候会授予二级锁。
    当一个客户端要求一个exclusive oplock或者batch oplock 的时候，服务器可能会选择用二级锁代替这两种锁，这是客户端在打开文件的时候获得二级锁的唯一方式。
    当服务器收回一个exclusive oplock或者batch oplock的时候，可能会结合着收回锁的时候授予一个二级锁。

oplock与其他文件加锁方法的对比

    cifs协议有三种机制保证客户端可以控制其他客户端对自己打开文件的访问。

• oplocks
• byte range locks
• sharing locks

这三种机制中，服务器只会撤回oplocks。另外两种锁由客户端决定要保持多久。
    在客户端系统的历史上，byte range和sharing locks是暴露给客户端的。这允许客户端明确的对这两种锁进行获取和释放。然而oplocks是不暴露给客户端的。他们是在客户端操作系统中实现的。客户端操作系统决定什么时候去获取以及释放oplocks。它也同时处理由服务器撤销锁引起的相关问题。

会影响oplock的SMB命令

The following SMB commands may be used to obtain an oplock:
获得一个oplock时可能用到的SMB commands：
- SMB_COM_OPEN
- SMB_COM_CREATE
- SMB_COM_CREATE_NEW
- SMB_COM_OPEN_ANDX
- SMB_COM_TRANSACTION2 (OPEN2)
- SMB_COM_NT_CREATE_ANDX
- SMB_COM_NT_TRANSACT (NT_CREATE)

在使用 SMB_COM_NT_CREATE_ANDX 和SMB_COM_NT_TRANSACT (NT_CREATE) 去打开文件获得锁的时候可能只会收到一个二级锁。

Release an oplocks释放锁

客户端通过SMB_COM_LOCKING_ANDX释放锁。要不然的话就会通过 SMB_COM_CLOSE command关闭文件时释放锁。任何使文件句柄无效的操作都会导致锁的释放。这包括disconnecting the tree, logging off the user that opened the file, and any action that would disconnect the session.
    客户端应该在服务器撤销exclusive和batch
locks的时候回应release锁，不这样做其实已经违反了协议本身。
    客户端不需要对撤销level 2 oplocks进行回应，但是这样做也并无问题。

Revoking an oplocks撤销锁

服务器通过发送SMB_COM_LOCKING_ANDX命令来撤销锁。这条命令在服务器发送给客户端的时候是异步的。这条信息会设置LOCKING_ANDX_OPLOCK_RELEASE flag位来表明oplocks破损了。 OplockLevel指明了当前客户端拥有哪种锁。如果 OplockLevel是0，那么客户端在这个文件上不具有任何锁。如果 OplockLevel是1，那么代表这是一个二级锁（Level 2）。当客户端不再使用这个文件的时候，客户端应该刷新任何dirty buffer到服务器，提交任何的文件锁，并且通过set了LOCKING_ANDX_OPLOCK_RELEASEflag 的 SMB_LOCKING_ANDX或者关闭文件的方式来回复服务器。

其他问题

    当服务器回收锁的时候可能会暂停掉不止一个的打开操作，直到收到了release oplock为止，经我测试发现一般是服务器向拥有锁的客户端发送一个SMB_COM_LOCKING_ANDX来撤销锁，客户端也会向服务器回复一个一模一样的SMB_COM_LOCKING_ANDX来表明锁已经撤销。在此之后服务器才会对其他的open命令进行回复。
    当一个客户端多次打开同一个文件的时候，和多个客户端是一样的，同样会有以上过程，其他的打开操作可以获得二级锁，如果服务器不想支持这样做的话，可以只是对同一个客户端访问的同一个文件只加一个二级锁，其他的都回复没有锁。
    一个对某个文件拥有exclusive或者batch oplocks的客户端可能会缓存文件的元数据，比如create time, modify time, access time, change time, file size, file attributes, and extended attributes size.无论如何，服务器并不会在第二个客户端检视这个文件的元数据时要求打断一个锁。客户端应该明白查询文件的元数据时并不需要打开文件。
    当一个服务器在撤销一个exclusive或者batch oplocks的时候可能会授予一个二级锁来替代原来的位置，客户端应该认为在它回应了release oplock之后这个二级锁就生效了。而服务器可能会在收到客户端的release oplock回应之前决定撤销那个二级锁。在这种情况下，客户端应该表现为这个二级锁的撤销命令是在它的release oplock之后到达的。

Security Model

每个服务器都会为网络上的客户端制造一系列的权限。一个被共享的资源可能是一个目录树，打印机等等。到目前为止客户端关心的是，这个服务器有没有存储或者服务是依赖于其他的服务器的。一个客户端认为服务器是被访问的文件（或者其他资源）的唯一供应商。