11.5.2 – 11.7.2Teacher: 周清江By 郎健如Date: 08/5/28

File Locking 為何會有複雜的 locking 技術 ?

◦ 常出現需要同時存取相同檔案時，因而有不同的 locks 存在。 File locking in NFSv4

◦ It is simple, only four operations related to locking. NonblockingNonblocking

◦ Lock 操作上通常會要求一連續範圍 (bytes) 的檔案讀或寫的鎖定。

Figure 11-18. NFSv4 operations related to file locking.

Client 端可去察看是否有相衝突的 lock 存在。Lock 的時間限定是由server 決定 , 如果 client 沒有將 locks 上的租期重新向 server 端申請 , 就會被 server移除。

Client 可向 server 要求建立在 lock 上的租期。

File Locking如果 client 所要求的鎖定和其他鎖定相衝突時會被拒絕，那 client 就會收到 error 訊息，一段時間後才會再去詢問 server 。FIFO-ordered list

◦ 另一種比較有效且公平的作法是 client 可要求被放入一個由server 端所維護的 FIFO-ordered list 。◦ 只要一有相衝的 lock 被移除， server 端就會允許 client 的下一個 lock 放在 FIFO-ordered list 最上方以供 client 在某段時間內的詢問。◦ 此方法可避免 server 端一直去通知 client 端，且非常公平，Clients 的 lock 要求都可參照 FIFO-ordered list 就可以得知目前 lock 的狀態。

File Locking Share reservation in NFS

◦ Share reservation 也是一種 lock 的鎖定，和 locking 是完全獨立的，被用來實做在 windows-based 的 NFS 上。◦ 當一個 client 端要開啟一個檔案時，會指定要存取的檔案型態 ( 也就是 READ,WRITE 或 BOTH) ，以及指定 server 端要拒絕其他 client 的存取型態 (NONE,READ,WRITE,or BOTH) 。如果 server 不能滿足 client 要求，那麼 client 開啟檔案就會失敗。

Figure 11-19. The result of an open operation with share reservations in NFS. (a) When the client requests shared access given the current denial state.

Client 端要求特定 access type, 會得到另一個 client 正在使用的狀態。

File Locking (cont.)

Figure 11-19. The result of an open operation with share reservations in NFS.(b) When the client requests a denial state given the current file access state.

Client 端要求現在正在使用的檔案狀態 (denial state) 。

Sharing files in coda 在 NFS 中此機制會命令最後的 process 被關閉時 , 狀態會回傳給 Server, 有任何 updates 同時發生時 , 最早的 session 會被遺失。 Coda file System( Kistler and Satyanaryanan, 1992)

◦ It uses a specialspecial allocation schemeallocation scheme to accommodate file sharing. 這機制和 NFS 裡的 Share reservations 類似。◦ Operation ：

Figure 11-20. The transactional behavior in sharing files in Coda.

Server 通知 client A 資訊過時。

以 transaction 的觀點來看 , 因為 session SA 在 session SB 之前發生 , 所以沒什麼關係。

Client-Side Caching Caching in NFS

◦ NFSv3 不同的 caching policy 就有不同的 caching 實做方式 , 大部分都會不一致 , 儘管實做上 ,client 可以擁有 old cached data for 30sec 而不知情。

◦ NFSv4 能以實做方式解決一致性問題，一般 NFS 所假設的 caching 模式如下：

Figure 11-21. Client-side caching in NFS.

Using the same

consistency parameters.

Client-Side Caching (Cont.) NFSv4 對於 caching file data 有兩種不同方式

◦ 當 client 讀取從 server 端檔案，用了大量的 read 。◦ Write 操作也能在 cache 中實現。當 client 關閉檔案時，如果檔案有任何變更， NFS 會要求 cached data 要傳回到 server 。 一旦 ( 部分 ) 檔案被 cached ， client即便關閉 file ，能保留在 cache 裡的資料。

NFS 要求無論何時 client 端開啟先前已關閉的檔案，都要馬上使 cached data 重新啟用重新啟用。 Cached data 何時重新啟用 (revalidation)

◦ 檢查檔案最近的更新時間◦ 當 cache 裡包含過時的資料

Client-Side Caching (Cont.) 在 NFSv4 中，當檔案被開啟時， server 可能會賦予一些 client 端權力。 當 client 被同一機器的其他 client 允許能本地處理開啟與關閉的操作， Open delegationOpen delegation 就會發生。正常來說， server 是負責檢查檔案是否有被成功開啟。 Open delegation

◦ Client 有時候被允許做一些決定以避免通知 server Ex： 假如 server 被 client 要求對開啟的檔案加以寫入，來自於其他 同一機器上的 client 對 file locking 的 request 也能本地端處理，但 server 會拒絕來自其他機器上 client 的存取要求。

◦ Client 有時候還是要通知 server Ex：假如 client 只做讀取的動作，其他 local client 發出寫入要求，就 要通知 server ，不可能直接在本地端處理這些 request 。

Client-Side Caching (Cont.) 收回委派收回委派 (recall the delegation)(recall the delegation) 的權力的權力

◦ Server賦予檔案的副本給 Client 時，最重要的要能夠要能夠回收檔案以便於讓其他 Client 能存取更新過的檔案。如下表：

Figure 11-22. Using the NFSv4 callback mechanism to recall file delegation. NFS 的 Callback 是使用 RPC 機制去做的。 NFS server 不可能實做為 stateless server 。

Question:結合 stateful server 和 delegation會有很大的問題 !萬一Server 指派 file 給不回應的 client呢 ?

Solution: lease

Client-Side Caching (Cont.) Write-through cache coherence policy

◦ Clients 可各自 cache attribute values ，但會有不一致的情形。透過此機制可將更改過的 attribute values 立即傳到 server 端。 為要減輕不一致的情形， NFS 使用 lease 在 cached attributes、 file handles 及 directories 上。 隨著時間經過，無效的 cache entries 要在再度被使用之前要能 revalidation 。

Client-Side Caching in Coda 此機制對於 Coda operation 來說是重要的兩個理由：

◦ Caching 可達成 scalability 。◦ Caching 有高度的容錯力，所以 client 比較不依賴於 Server 的可用性。

Cache coherence( 讀取連貫 ) 在 coda 中是由 callbacks 所維護。 Callback promiseCallback promise: server 端會持續追蹤 client從 server 那裡得到的檔案 (local copy) ，即 server 可以被說成是記錄一個 client 端的 callback promise 。 Callback breakCallback break: 一旦 client 端檔案被更新就會通知 server ， server 會端發出 invalid message 給其他 client 。一個 invalid message 就叫一個 callback break 。當 server 發出 invalid message 給 client 時，會丟掉原本在 client 所持有的 callback promise 。

Client-Side Caching in Coda (Cont.)

Figure 11-23. The use of local copies when opening a session in Coda.

Client B更新檔案通知 server,由 server 發出 callback break,並丟棄原本持有 client A 的 callback promise 。

Client B想要開啟 session S’B, 也去check server還持有自己的 callback promise, 所以 Client B 可以繼續使用 Session B 的 local copy 。

Client A 在開啟 Session S’A 之前 , 發現自己檔案 f 的 local copy已無效所以向 server 重新取得新的版本。

Client 開啟 Session SA, Server 端就記錄一個

Callback promise

Client-Side Caching for Portable Devices 很多設備為非永久性連結非永久性連結， ex: PDA、筆記型電腦裝置以及可攜式多媒體裝置 (ex:電影或聲音播放器 ) 。 大部分的情況都是以上傳上傳 // 下載模式下載模式來維護可攜式裝置裡的檔案。檔案通常儲存在 local 端的設備或是透過網路連結到系統。 Tolia et al. (2004)提出一個很簡單的方法：將以密碼加密的 hash 資料儲存在檔案中。這些 hashes儲存在可攜式裝置上，用來將 request導向到相關的內容 /頁面上。

◦ 當檔案被擷取時，系統會檢查檔案是否可在 local 端取得以及檔案是否為最新的資料。請注意舊有資料會有不同的 hash ，如果檔案可在本地端取得，就會傳回給 client ，否則就是透過網路傳輸資料。 未來期望 user 會使用特別的程式事先在設備上安裝好檔案。

Server-Side Replication Server 端的複製技術在分散式的檔案系統裡很少見，為要因應緊急時需要能快速取得資料所以才有複製的應用。 從績效的觀點來看

◦ 在整個檔案或大部分的檔案上用 cache ，效率會來得更好。◦ 高度複製但讀取 / 寫入比率過低，效率也會降低。因為每更新一次就需要一次 replica, 所以同步更新需要用到同步化的技術，導致需要更多的溝通與績效的低落。

基於上述理由，檔案伺服器通常只為了要容錯時才會複製。

Server Replication in Coda Coda

◦ 允許檔案伺服器上的複製。◦ 使用 replicated-write協定去維護 volume副本的一致性。◦ 特別也使用 ROWA 的變形。

Volume◦ 是以一群檔案為單位的複製。◦ 一個 volume 是對應一個 Unix 硬碟分割區。

Volume Storage Group (VSG)◦ 一群 Coda servers 有著一份 volume 的 copy ，名為 volume 的 Volume Storage Group 。◦ 如果有失敗情形發生， Client 就不能存取所有在 VSG中的 Server 。

Accessible Volume Storage Group (AVSG) ◦ 為 Client 端所能存取的 VSG， Client 可聯繫存在 VSG裡的 Server 。如果AVSG是空的，則 Client 端就被稱為是 disconnected 。

每個 Server 會為每一 file 維護 coda version vector 。

Server Replication in Coda (Cont.) ROWA (Read-one, Write All) 的變形：

◦ 當 Client 需要讀取一個檔案，就會聯繫關於位在此檔案裡的 AVSG的 member 。當關閉已更新的檔案， Client 會平行傳輸此更新檔給 AVSG裡每一 member 。這種平行傳輸可藉由MultiRPC 來完成。

Figure 11-24. Two clients with a different AVSG for the same replicated file.

有一檔案的副本存於 Server S1,S2,S3 。而 Server S1,S2 是Client A 可存取的AVSG 。利用 Coda version vector:

CVVi(f)[i] 為存於 Server Si 中 file 目前版本個數

CVVi(f)[j]=k即是 Serveri 知道 Serverj 擁有 f至少 k 個最新版本的個數。Client B 可存取的 AVS

G 是在 Server S3 上。

Client A更新檔案後傳給 Server S1,S2 CVV1(f)=CVV2(f)=[2,2,1]ClientB更新檔案後傳回 Server S3CVV3(f)=[1,1,2]當 Broken network修復了，三個 server勢必要重新整合各自的 file copy ，並比較各自 version vector 來修復彼此相衝的版本。大部分情況下，版本衝突可依賴應用程式自動解決，或人為處理。

Structured Peer-to-Peer Systems 由 Gopalakrishnan et al. (2004) 所提出，能在 peer-to-peer 間平衡負載的查詢機制，即查詢路徑上所有節點的 load 都考量到。 當 R檢查完有檔案要下載給 P，又有很多其他的節點也向 R索求檔案的話，就會要求 P複製檔案的副本 (數量要是 R 被索求檔案的最大數量 ) 。中間的節點則有 pointer 指向 P，當 pointer所指向到的檔案沒有再被要求時就會很快被移除。

Figure 11-25. Balancing load in a peer-to-peer system by replication.

File Replication in Grid Systems 在 Grid 所應用的資料都是 read only ，且鮮少更新。資料的來源都是從 sensors 或是其他的 applications 來的。也因此可以大量的應用 data replication 。 但資料集的 size 有時過於龐大，需要一些測量機制以避免 data providers(儲存在資料的機器 ) 在資料傳輸於網路上負擔過重。 Grid systems 中的複製技術

◦ 已演化到在最佳的來源上複製資料的問題。這種問題可由 replicatreplication servicesion services 解決，類似之前討論過的 naming system 的 location service 。即 client 端可利用 FTP的協定下載檔案，用 replication location services註冊即可取得 replication 。◦ 還有一個最明顯的方法就是使用之前討論過的 DHT-based system可以減少 replicas 被集中查詢的問題。

Handling Byzantine Failures 應用：

◦ 分散式系統，尤其是在 NFS系統上。 Basic idea

◦ 藉由建構一組 finite state machines 以主動指派 replication 以及在這一組中有些 nonfaulty processes 可以執行相同順序的操作。◦ 假設至多有 k 個 processes 立即 fail ， client 會送出 operation 給整個 group ，然後收到至少 k+1 不同的 processes 。◦ 為要避免 Byzantine failures ， server group必定至少要有 3k+1 processes.◦ Processes 有一系列的 views ，每個 view 的 member 都同意 nonfaulty processes 及當現有的 master掛掉時，要能啟動一個新的 view 。

Handling Byzantine Failures (Cont.) Quorum mechanism

◦ 能確保每個 request 的順序都相同。◦ quorum certificatequorum certificate

當 process 收到 request 時 , 將它送給其他 process,並確保收到至少 2k+1 個 process 收到相同的 request 之確認訊息確認訊息。

Figure 11-26. The different phases in Byzantine fault tolerance.

Master 收到client 的 request 後隨即廣播相關操作的 sequence number 。

Client送出 request 給所有整個 ser

ver group 。

Slave Replicas 收到後也接受由 master 傳來的 sequence number ，它就把這接受的訊息廣播出去。

此階段是由每個 process 去告訴 others 存在自己 local 端的 request log 。因為 crash 時，每個 process 也能根據哪個 view、哪個 sequence number 被指派做復原。

High Availability in Peer-to-Peer SystemsRedundancy

◦ 可確保在 peer-to-peer系統中的可用性。◦ 當談到檔案時，實際上可以透過兩個不同的方法來瞭解它：

Replication Erasure coding

是一個有名的技術，即是把檔案分成m 個區段再隨後加以編碼成 n區段，但 n>m區段。 重要的是只要任何一組m 個編碼過的區段就足以重建整個原始檔案。 假設節點平均的可用性為 a ， ε 表示部分檔案不能取得，但我們必須保證至少有 m 個區段是可以獲得的。 1- ε= ai(1-a)n-i

High Availability in Peer-to-Peer Systems (Cont.) 如果假設 node 是分開的且是分散的，我們可以說 1- ε=1-(1-a)rrep

我們可以考慮在節點可用度 a 關係上 rrep /rec 的比率來表達 replication與 erasure coding 之間的不同。

Figure 11-27. The ratio rrep /rec as a function of node availability a.

High Availability in Peer-to-Peer Systems (Cont.) 從上圖可看出在所有情形下， erasure coding 需要的 redundancy 會比 replicating files還少。換句話說， replicating files 是為要增加 peer-to-peer網路節點的可用度，但從儲存的空間來看沒有比使用 erasure coding 來得有效率。 維護 redundancy 會增加 communication ，那麼越低的 redundancy 就可以更節省頻寬的使用。 當這些節點對應到的 user machines 所透過非對稱 DSL 或 cable lines 連上網際網路時，效率就變的明顯重要。因為連出的link 通常只有每秒幾百 k 的大小而已。