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

每個伺服器都會為網絡上的用戶端制造一系列的權限。一個被共享的資源可能是一個目錄樹，列印機等等。到目前為止用戶端關心的是，這個伺服器有沒有存儲或者服務是依賴于其他的伺服器的。一個用戶端認為伺服器是被通路的檔案（或者其他資源）的唯一供應商。