就行程而言，分散式檔案系統沒有什麼特殊之處：多半是不同類型的協作行程，如儲存伺服器與檔案管理者，正如前一節各種組織所描述的那樣。

最值得討論的問題是：**檔案系統行程該不該是無狀態（stateless）的？**NFS 正是說明其中權衡的好例子。相較於其他分散式檔案系統，NFS 長年的招牌特色就是伺服器無狀態——協定不要求伺服器維護任何用戶端狀態。v2 與 v3 都遵循此路線，v4 則放棄了。

無狀態的優點與極限#

無狀態的主要優點是簡單：無狀態伺服器當機後，基本上不需要進入回復階段把伺服器帶回先前狀態。不過仍要注意，用戶端得不到「請求是否確實已被執行」的任何保證。

實務上，NFS 協定的無狀態路線也無法完全貫徹：

• 檔案鎖定很難由無狀態伺服器處理——NFS 因此用獨立的鎖管理者（lock manager）來處理。
• 某些認證協定也要求伺服器維護用戶端狀態。

儘管如此，NFS 伺服器大體上仍能設計成只需維護極少的用戶端資訊，這套方案多數情況運作良好。

NFSv4 轉向有狀態#

自 v4 起無狀態路線被放棄，但新協定的設計仍讓伺服器不必維護太多用戶端資訊。選擇有狀態（stateful）還有其他理由：

• 廣域網路的快取一致性：NFSv4 預期要跨廣域網路運作，用戶端必須能有效利用快取，因此需要高效率的快取一致性協定。這類協定通常在「伺服器維護一些用戶端使用檔案的資訊」時運作得最好——例如伺服器可對交給用戶端的檔案附上租約（lease），承諾在租約到期或續約前給予該用戶端獨占的讀寫權。
• open 操作：v4 與舊版最明顯的差異就是支援 open。
• 回呼（callback）：NFSv4 支援伺服器對用戶端發起 RPC 的回呼程序，這顯然也要求伺服器記住它的用戶端。

同樣的推理也影響了其他分散式檔案系統的設計：維持完全無狀態的設計相當困難，實務上往往走向以有狀態的解法作為強化，NFS 的檔案鎖定正是如此。