在存儲系統(tǒng)中， NFS(Network File System，即網(wǎng)絡(luò)文件系統(tǒng))是一個重要的概念，已成為兼容POSIX語義的分布式文件系統(tǒng)的基礎(chǔ)。它允許在多個主機(jī)之間共享公共文件系統(tǒng)，并提供數(shù)據(jù)共享的優(yōu)勢，從而最小化所需的存儲空間。本文將通過分析NFS文件鎖狀態(tài)視圖一致性的原理，幫助大家理解NFS的一致性設(shè)計思路。

文件鎖

文件鎖是文件系統(tǒng)的最基本特性之一，應(yīng)用程序借助文件鎖可以控制其他應(yīng)用對文件的并發(fā)訪問。NFS作為類UNIX系統(tǒng)的標(biāo)準(zhǔn)網(wǎng)絡(luò)文件系統(tǒng)，在發(fā)展過程中逐步地原生地支持了文件鎖(從NFSv4開始)。NFS從上個世界80年代誕生至今，共發(fā)布了3個版本：NFSv2、NFSv3、NFSv4。

NFSv4最大的變化是有“狀態(tài)”了。某些操作需要服務(wù)端維持相關(guān)狀態(tài)，如文件鎖，例如客戶端申請了文件鎖，服務(wù)端就需要維護(hù)該文件鎖的狀態(tài)，否則和其他客戶端沖突的訪問就無法檢測。如果是NFSv3就需要NLM協(xié)助才能實現(xiàn)文件鎖功能，但是有的時候兩者配合不夠協(xié)調(diào)就會容易出錯。而NFSv4設(shè)計成了一種有狀態(tài)的協(xié)議，自身就可以實現(xiàn)文件鎖功能，也就不需要NLM協(xié)議了。

應(yīng)用接口

應(yīng)用程序可以通過 fcntl() 或 flock() 系統(tǒng)調(diào)用管理NFS文件鎖，下面是NAS使用NFSv4掛載時獲取文件鎖的調(diào)用過程：

??

從上圖調(diào)用棧容易看出，NFS文件鎖實現(xiàn)邏輯基本復(fù)用了VFS層設(shè)計和數(shù)據(jù)結(jié)構(gòu)，在通過RPC從Server成功獲取文件鎖后，調(diào)用 locks_lock_inode_wait() 函數(shù)將獲得的文件鎖交給VFS層管理，關(guān)于VFS層文件鎖設(shè)計的相關(guān)資料比較多，在此就不再贅述了。

EOS原理

文件鎖是典型的非冪等操作，文件鎖操作的重試和Failover會導(dǎo)致文件鎖狀態(tài)視圖在客戶端和服務(wù)端間的不一致。NFSv4借助SeqId機(jī)制設(shè)計了最多執(zhí)行一次的機(jī)制，具體方法如下：

針對每個open/lock狀態(tài)，Client和Server同時獨立維護(hù)seqid，Client在發(fā)起會引起狀態(tài)變化的操作時(open/close/lock/unlock/release_lockowner)會將seqid加1，并作為參數(shù)發(fā)送給Server，假定Client發(fā)送的seqid為R，Server維護(hù)的seqid為L，則：

• 若R == L +1，表示合法請求，正常處理之。
• 若R == L，表示重試請求，Server將緩存的reply返回即可。
• 其他情況均為非法請求，決絕訪問。

根據(jù)上述規(guī)則，Server可判斷操作是否為正常、重試或非法請求。

該方法能夠保證每個文件鎖操作在服務(wù)端最多執(zhí)行一次，解決了RPC重試帶來的重復(fù)執(zhí)行的問題，但是僅靠這一點是不夠的。比如LOCK操作發(fā)送后調(diào)用線程被信號中斷，此后服務(wù)端又成功接受并執(zhí)行了該LOCK操作，這樣服務(wù)端就記錄了客戶端持有了鎖，但客戶端中卻因為中斷而沒有維護(hù)這把鎖，于是就造成了客戶端和服務(wù)端間的鎖狀態(tài)視圖不一致。因此，客戶端還需要配合處理異常場景，最終才能夠保證文件鎖視圖一致性。

異常處理

由上一節(jié)的分析可知，客戶端需要配合處理異常場景才能夠保證文件視圖一致性，那么客戶端設(shè)計者主要做了哪些配合的設(shè)計呢?目前客戶端主要從SunRPC和NFS協(xié)議實現(xiàn)兩個維度相互配合解決該問題，下面分別介紹這兩個維度的設(shè)計如何保證文件鎖狀態(tài)視圖一致性。

SunRPC設(shè)計

SunRPC是Sun公司專門為遠(yuǎn)程過程調(diào)用設(shè)計的網(wǎng)絡(luò)通訊協(xié)議，這里從保障文件鎖視圖一致性的維度來了解一下SunRPC實現(xiàn)層面的設(shè)計理念：

(1)客戶端使用int32_t類型的xid標(biāo)識上層使用者發(fā)起的每個遠(yuǎn)程過程調(diào)用過程，每個遠(yuǎn)程過程調(diào)用的多次RPC重試使用相同的xid標(biāo)識，這樣就保障了多次RPC重試中任何一個返回都可以告知上層遠(yuǎn)程過程調(diào)用已經(jīng)成功，保證了服務(wù)端執(zhí)行遠(yuǎn)程過程調(diào)用執(zhí)行耗時較長時也能拿到結(jié)果，這一點和傳統(tǒng)的netty/mina/brpc等都需要每個RPC都要有獨立的xid/packetid不同。

(2)服務(wù)端設(shè)計了DRC(duplicate request cache)緩存最近執(zhí)行的RPC結(jié)果，接收到RPC時會首先通過xid檢索DRC緩存，若命中則表明RPC為重試操作，直接返回緩存的結(jié)果即可，這在一定程度上規(guī)避了RPC重試帶來的重復(fù)執(zhí)行的問題。為了避免xid復(fù)用導(dǎo)致DRC緩存返回非預(yù)期的結(jié)果，開發(fā)者通過下述設(shè)計進(jìn)一步有效地減少復(fù)用引起錯誤的概率：

客戶端建立新鏈接時初始xid采用隨機(jī)值。

服務(wù)端DRC會額外記錄請求的校驗信息，緩存命中時會同時校驗這些信息。

(3)客戶端允許在獲得服務(wù)端響應(yīng)前無限重試，保證調(diào)用者能夠獲得服務(wù)端確定性的執(zhí)行結(jié)果，當(dāng)然這樣的策略會導(dǎo)致無響應(yīng)時調(diào)用者會一直hang。

(4)NFS允許用戶在掛載時通過soft/hard參數(shù)指定SunRPC的重試策略，其中soft模式禁止超時后重試，hard模式則持續(xù)重試。當(dāng)用戶使用soft模式掛載時NFS實現(xiàn)不保證客戶端和服務(wù)端狀態(tài)視圖的一致性，在遇到遠(yuǎn)程過程調(diào)用返回超時要求應(yīng)用程序配合狀態(tài)的清理和恢復(fù)，比如關(guān)閉訪問出錯的文件等，然而實踐中很少有應(yīng)用程序會配合，所以一般情況下NAS用戶都使用hard模式掛載。

總之，SunRPC要解決的核心問題之一是，遠(yuǎn)程過程調(diào)用執(zhí)行時間是不可控的，協(xié)議設(shè)計者為此定制化設(shè)計，盡量避免非冪等操作RPC重試帶來的副作用。

信號中斷

應(yīng)用程序等待遠(yuǎn)程過程調(diào)用結(jié)果時允許被信號中斷。當(dāng)發(fā)生信號中斷時，由于沒有得到遠(yuǎn)程過程調(diào)用的執(zhí)行結(jié)果，所以客戶端和服務(wù)端的狀態(tài)很可能就不一致了，比如加鎖操作在服務(wù)端已經(jīng)成功執(zhí)行，但客戶端并不知道這個情況。這就要求客戶端做額外的工作將狀態(tài)和服務(wù)端恢復(fù)一致。下面簡要分析獲取文件鎖被信號中斷后的處理，來說明NFS協(xié)議實現(xiàn)層面的一致性設(shè)計。

通過獲取NFSv4文件鎖的過程可知，NFSv4獲取文件鎖最終會調(diào)用 _nfs4_do_setlk() 函數(shù)發(fā)起RPC操作，最終調(diào)用 nfs4_wait_for_completion_rpc_task() 等待，下面是相關(guān)代碼：

static int _nfs4_do_setlk(struct nfs4_state *state, int cmd, struct file_lock *fl, int recovery_type)  
 {       
   ......      
   task = rpc_run_task(&task_setup_data);      
   if (IS_ERR(task))          
       return PTR_ERR(task);      
   ret = nfs4_wait_for_completion_rpc_task(task);      
   if (ret == 0) {          
       ret = data->rpc_status;          
       if (ret)              
               nfs4_handle_setlk_error(data->server, data->lsp,                      
                   data->arg.new_lock_owner, ret);      
       } else          
           data->cancelled = 1;        
   ......      
 }

通過分析 nfs4_wait_for_completion_rpc_task() 實現(xiàn)可知，當(dāng)ret < 0時，表明獲取鎖過程被信號中斷，并使用 struct nfs4_lockdata 的 cancelled 成員記錄。繼續(xù)查看rpc_task完成后釋放時的回調(diào)函數(shù) nfs4_lock_release()：

??

從上面紅色框中的代碼可知，nfs4_lock_release() 檢測到存在信號中斷時會調(diào)用 nfs4_do_unlck()函數(shù)嘗試將可能成功獲得文件鎖釋放掉，注意此時沒有調(diào)用 nfs_free_seqid() 函數(shù)將持有的nfs_seqid釋放掉，這是為了：

• 保證訂正狀態(tài)過程中不會有用戶新發(fā)起的并發(fā)加鎖或者釋放鎖操作，簡化實現(xiàn)。
• 保證hard模式下UNLOCK操作只會在LOCK操作返回后才會發(fā)送，保障已經(jīng)獲得鎖能夠被釋放掉。

客戶端通過上面的方法能夠有效地保證信號中斷后客戶端和服務(wù)端鎖狀態(tài)的最終一致性,但也是在損失一部分可用性為代價的。

總結(jié)

文件鎖是文件系統(tǒng)原生支持的基礎(chǔ)特性，NAS作為共享的文件系統(tǒng)要面臨客戶端和服務(wù)端鎖狀態(tài)視圖一致性的問題，NFSv4.0在一定程度上解決了這個問題，當(dāng)然，技術(shù)前進(jìn)的腳步不會停止，NFS的更新迭代也就不會停止，未來的NFS將會有更多的期待。

最后

我們相信技術(shù)的力量，更相信擁有技術(shù)力量的人。我們期待存儲的未來，更期待與你一起創(chuàng)造未來。