分布式文件系統近來沒有什麼新聞，因為使用它們的主要是公司和教育網絡，總共只有幾千個用戶。從概念上來說，對於這樣的系統如何適合開放源碼文件系統這個領域，還並非總是很清楚。Open Andrew File System (OpenAFS) 是對 Network File System (NFS) 的成熟的替代方案，它能適應大量的用戶，並能減輕管理的痛苦。
用戶對文件系統的概念有兩種理解。第一種是組織文件的方式、包含文件的目錄，以及保存目錄結構的分區。第二種認為文件系統是文件組織和映射到原始材料的方式。當然，在這兩者之間還存在很多層，如虛擬文件系統 (VFS) 層和實際存儲管理例程，但是就管理用戶可用的結構化信息而言，超級用戶看一下系統內部，並對內核的最深處有一些了解是很有意義的。
原始材料可能由 RAM 或硬盤組成，但是不管是哪種情況，文件系統數據結構都是組織由硬件制造商格式化了的扇區和字節。盡管這種劃分相當粗糙，用戶在他們的工作生活中還是能夠十分愉快地接受這種劃分。提高 —— 比如說，用戶訪問比特定容量大的文件的速度 —— 的工具是可用的。幫助重新組織目錄和文件的工具也是可用的，但是這些工具使我們遠離比特、字節和扇區。
文件系統元概念
這種總體區分的一個經典例子就是 FreeBSD —— 回溯到 BSD UNIX® 時代 —— 用 UNIX File System V2 (UFS2) 來組織磁盤上的數據而用 Flash File System (FFS) 來把文件組織成目錄並最優化目錄訪問的方式。Linux® 系統有些不同，因為 Linux 本來就容許有不限於一個或兩個的文件系統。因此，VFS 層使 Linux 用戶可以添加新的文件系統支持而不必過於擔心 Linux 管理存儲器的方式。
當我談到進一步的區分，如靜態和日志文件系統時，我要強調一致性以及某種程度上的文件系統內容的安全性。同樣，用 BSD UNIX 時代用來看問題的術語來說, 靜態和日志 文件系統與 UNIX File System (UFS) 組織文件並確保其安全的方式有關。雖然 Linux 文件系統從 Journal File System (JFS) 開始就包含了日志文件系統，但是下一代文件系統 (XFS) 和早期的 ReiserFS 也被改造成對其可用，還有一個不管是技術媒體還是公司宣傳都沒有過多提及的領域就是分布式文件系統。
從 NFS 所學到的
這種情況與這樣的現實有關：如今，使網絡范圍內的文件系統層變成對相當多的用戶來說通過 TCP 或 User Datagram Protocol (UDP) 就可用，這種做法是非常輕率的。圍繞 NFS V3 之前版本的恐怖場景使許多管理人員不願管理哪怕只有幾十個用戶的網絡。此外，由極快的主板架構支持的多處理器架構的出現，似乎使得分布式文件系統問題變得不太重要。 速度似乎是由硬件保證的，而不是由智能實現的分布式系統保證的。由於分布式文件系統往往要依賴於底層的文件系統實現 —— 例如，已有的 ext2、ext3 和 ReiserFS 文件系統驅動程序 —— 分布式文件系統好像僅限於大的大學網絡和臨時的科研和公司網絡這些領域。
那麼，分布式文件系統是否是我們所提及的兩層之上的第三層呢？如今聯網過程中的一個重要問題就是使異構的網絡合作（Samba 是一個很好的例子）。但是您要明白，今天在文件系統領域有三家主要制造商：Microsoft® Windows®文件系統系列（FAT16、FAT32 和 NTFS 文件系統）；Apple Mac OS X (HFS+)；以及本機 Linux 日志文件系統（主要是 ReiserFS 和 ext3）。Samba 幫助使 Windows 和 Linux 文件系統合作，但是它並沒有使管理人員對所有主要文件系統上的訪問都同樣地快速和容易。
有人可能會引用 NFS V4 作為解決該問題的一次嘗試，但是由於處理 NFS V4 的 Request for Comments (RFC) 3530 才發布兩年，而且針對內核 V2.6 的 NFS4 還相當新，我暫不推薦使用它做生產服務器。Fedora 核心 2 和 3 提供了 NFS4 補丁和 NFS4 實用程序，這些實用程序演示了開發人員完成的一些印象非常深刻的過程，因為 NFS 強制可憐的網絡管理人員，打開更多的端口並為導出到用戶的每個名稱空間配置各自的客戶機。RFC 3530 解決了大部分的安全問題。還有，NFS 目錄必須單獨安裝。您可以用統一的 sign-on 和 Kerbero 來保證安全，但是那也需要做很多工作。
OpenAFS 基本原理
OpenAFS 試圖免除安裝和管理用於使不同文件系統合作的軟件時的痛苦。OpenAFS 也能使不同文件系統更有效地合作。盡管 UNIX 及其引人注目的後繼者 Plan 9 的最初目標是文件，但是商業現實指出，與其徹底重構現代的網絡文件系統，不如添加另一個分布式文件系統層。
1983 年 Carnegie Mellon University 的編程人員開發了 AFS。此後不久，該大學成立了一家叫做 Transarc 的公司來出售基於 AFS 的服務。1998 年 IBM 收購了 Transarc，並使 AFS 成為一個開放源碼產品，叫做 OpenAFS。但是，故事並未就此結束，因為 OpenAFS 衍生了其他的分布式文件系統，如 Coda 和 Arla，這些我將在後面談到。存在針對所有主要操作系統的各種客戶機，及大量的過時文檔資料。Gentoo.org 為使 OpenAFS 對 Linux 用戶可用做出了特別貢獻，即使其他機構在需要分布式文件系統時似乎仍然是指 NFS。
OpenAFS 架構
OpenAFS 是圍繞一組叫做 cell 的文件服務器組織的。每個服務器的標識通常是隱藏在文件系統中的。從 AFS 客戶機登錄的用戶將分辨不出他們在哪個服務器上運行，因為從用戶的觀點來看，他們想在有可識別的 UNIX 文件系統語義的單個系統上運行。文件系統內容通常都是跨 cell 復制，以便一個硬盤的失效不會損害 OpenAFS 客戶機上的運行。OpenAFS 需要高達 1 GB 的大容量客戶機緩存，以允許訪問經常使用的文件。它還是一個十分安全的基於 Kerbero 的系統，它使用訪問控制列表 (ACL) 以便可以進行細粒度的訪問，這不是基於通常的 Linux 和 UNIX 安全模型。
緩存管理器碰巧是 OpenAFS 的一部分，很奇怪，它只作為底層文件系統與 ext2 一起運行。除緩存管理器之外，OpenAFS 表層的基本結構很像現代的 NFS 實現。但是，基本架構卻一點都不像，而且必須慎重看待它的任何並行。對那些仍喜歡使用 NFS，但是又想利用 OpenAFS 程序的人來說，可以使用所謂的 NFS/AFS 翻譯器。只要 OpenAFS 客戶機被配置為 NFS 服務器機器，您就應該能夠享受這兩種文件系統的優點。
OpenAFS 如何進行管理
NFS 是位置無關的，它把本地目錄映射到遠程文件系統位置。OpenAFS 對用戶隱藏了文件位置。因為可能所有的源文件都以讀寫副本的形式保存在復制到的不同文件服務器位置上，必須保持復制的副本同步。為此要使用一項稱作 Ubik 的技術，它源於單詞“ubiquitous（無所不在）”，是東歐拼寫法。Ubik 過程使 AFS 文件系統上的文件、目錄和卷 (volume) 保持同步，但是通常運行三個以上文件服務器進程的系統獲益最多。系統管理人員可以將一個 AFS 站點的幾個 AFS cell 分組 —— 這個以前的縮寫詞 AFS 已經被保留在 OpenAFS 文件系統的語義中了。管理人員將決定 AFS cell 的數目，以及 cell 使存儲器和文件對站點內的其他 AFS cell 可用的程度。
分區、卷和目錄
AFS 管理人員把 cell 劃分為所謂的卷。雖然卷可以隨硬盤分區協同擴展 (co-extensive)，但大多數管理人員都不會將整個分區只分為一個卷。AFS 卷實際上是由一個單獨的、稱作 Volume Manager 的 UNIX 類型的進程管理的。您可以以一種常見的方式從 UNIX 文件系統目錄安裝卷。但是，您可以將 AFS 卷從一個文件服務器移動到另一個文件服務器 —— 同樣是由一個 UNIX 類型的進程來管理的 —— 但是 UNIX 目錄不能從一個分區實際地移動到另一個分區上。AFS 通過 Volume Location Manager 自動跟蹤卷和目錄的位置，並留意復制的卷和目錄。因此，每當文件服務器非預期地停止操作，用戶根本無需擔心，因為 AFS 會把用戶切換到另一個文件服務器機器上的復制卷，而用戶可能都不會注意到。
用戶從來不對 AFS 服務器上的文件進行操作。他們操作已經由客戶端緩存管理器從文件服務器中取出的文件。Cache Manager 是居留在客戶機操作系統內核中的一只非常有趣的猛獸。（您可以在 2.4 版本以上的任何內核中運行 Cache Manager）。
Cache Manager
Cache Manager 可以響應本地應用程序的請求，來跨 AFS 文件系統取出文件。當然，如果該文件是經常更改的源文件，那麼文件存在於幾個復制版本中可能不太好。因為用戶很可能要頻繁地更改經常被請求的源文件，所以您會遇到兩個問題：首先，文件很可能被保存在客戶機緩存內，而同時還保存在幾個文件服務器機器上的幾個復制卷內；然後，Cache Manager 不得不更新所有的卷。文件服務器進程把文件發送到客戶機緩存內並隨其附帶一個回調，以便系統可以處理發生在其他地方的任何更改。如果用戶更改了緩存在其他地方的復制文件，原始文件服務器將會激活回調，並提醒原始緩存版本它需要更新。
分布式版本控制系統也面臨這個經典問題，但是有一點重要的區別：分布式版本控制系統在斷開時可以運行得很好，而 AFS 文件系統的任一部分都不能斷開。斷開的 AFS 部分無法再次與原來的文件系統連接。失效的文件服務器進程必須與仍在運行的 AFS 文件服務器重新同步，但是不能添加可能在它斷開後保存在本地的新更改。
AFS 的後代
由於一些對新文件系統的嘗試，AFS 已經明顯要退出了。兩個這樣的結合了開發人員從原始分布式文件系統架構中學到的經驗的系統就是：Coda 和瑞典開放源碼志願者的成果 Arla。
Coda 文件系統是改進原始的 AFS 系統的第一次嘗試。1987 年在 Carnegie Mellon University，開發人員想要使 Coda 成為對 AFS 的一次自覺的改進，當時 AFS 達到了 V2.0 版本。在上個世紀 80 年代末 90 年代初，Coda 文件系統首次發布了一個不同的緩存管理器：Venus。雖然 Coda 的基本功能集與 AFS 的類似，但是 Venus 支持支持 Coda 的客戶機的連續操作，即使客戶機已經從分布式文件系統斷開了。Venus 具有與 AFS Cache Manager 完全相同的功能，即把文件系統任務從內核內部的 VFS 層取出。
Coda 服務器和 Venus 緩存管理器之間的連接故障並不總損害網絡功能：膝上型客戶機必須能離開中央服務器工作。因此，Venus 把所有的更新存儲在客戶機修改日志內。當緩存管理器與中央服務器重新連接時，系統重建客戶機修改日志，使所有的文件系統更新對客戶機都可用。
斷開操作可能引起其他問題，但是 Venus 緩存管理器說明了分布式文件系統可以被擴展，以包含比總是以連接方式運行的網絡復雜得多的網絡。
從 1993 年起，編程人員就開始開發 Arla，這是一個提供 OpenAFS 的 GPL 實現的瑞典項目，但是大部分的開發和端口都發生在 1997 年以後。Arla 模仿 OpenAFS 模仿得非常好，只是 XFS 文件系統必須運行在所有運行 Arla 的操作系統上。Arla 已經達到 V0.39 版本了，而且，就像 OpenAFS 一樣，運行在所有的 BSD 流派、內核 V2.0x 版本以上的許多 Linux 內核以及 Sun Solaris 之上。Arla 確實為 AFS 實現了一個原本不在 AFS 代碼中的功能：斷開操作。但是具體情況可能會不同，開發人員也還沒有完成測試。
還有其他的 AFS 類型的文件系統，如 GPLed InterMezzo，但是它們沒有照搬 AFS 的命令行語義或它的架構。開放源碼分布式文件系統領域是非常活躍的，其他分布式文件系統在移動計算領域得到了應用。