用户对文件系统的概念有两种理解。第一种是组织文件的方式、包含文件的目录，以及保存目录结构的分区。第二种认为文件系统是文件组织和映射到原始材料的方式。当然，在这两者之间还存在很多层，如虚拟文件系统 (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 ManagerCache 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 的命令行语义或它的架构。开放源码分布式文件系统领域是非常活跃的，其他分布式文件系统在移动计算领域得到了应用。 |
