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

文件鎖

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

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

應(yīng)用接口

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

??

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

EOS原理

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

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

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

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

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

異常處理

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

SunRPC設(shè)計(jì)

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

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

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

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

服務(wù)端DRC會(huì)額外記錄請(qǐng)求的校驗(yàn)信息，緩存命中時(shí)會(huì)同時(shí)校驗(yàn)這些信息。

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

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

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

信號(hào)中斷

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

通過獲取NFSv4文件鎖的過程可知，NFSv4獲取文件鎖最終會(huì)調(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() 實(shí)現(xiàn)可知，當(dāng)ret < 0時(shí)，表明獲取鎖過程被信號(hào)中斷，并使用 struct nfs4_lockdata 的 cancelled 成員記錄。繼續(xù)查看rpc_task完成后釋放時(shí)的回調(diào)函數(shù) nfs4_lock_release()：

??

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

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

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

總結(jié)

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

最后

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