安德鲁文件系统-AFS
2020-10-13 12:57:44 
阿炯
安德鲁文件系统(英语：Andrew File System，缩写为AFS)，一种分布式文件系统，由卡内基美隆大学开发的文件系统。于1982年开始开发，是安德鲁计划的一部分，为了纪念安德鲁·卡内基与安德鲁·W·梅隆而命名，用于分布式计算之中。安德鲁文件系统最早是为了学术研究而开发，作为研究及校园内使用，AFS系统仍然属于IBM公司。OpenAFS、Arla与Coda是它的开放源代码版本与分支版本，但目前仅有OpenAFS还在持续开发中。它的主要功能是用于管理分布在网络不同节点上的文件，与普通文件系统相比，AFS的主要特点在于三个方面：分布式、跨平台、高安全性。
AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for federated file sharing and replicated read-only content distribution, providing location independence, scalability, security, and transparent migration capabilities. AFS is available for a broad range of heterogeneous systems including UNIX, Linux, MacOS X, and Microsoft Windows.
IBM branched the source of the AFS product, and made a copy of the source available for community development and maintenance. They called the release OpenAFS.
1987年，卡内基梅隆大学由AFS-2中，分支出Coda，主要是使用于笔记本电脑上。1989年，Transarc公司获取AFS的商业性开发权利，开始销售AFS，提供商业使用。1993年，瑞典皇家工学院利用AFS的分支，开发了Arla。1994年，IBM并购了Transarc公司，同时也得到这套软件。2000年8月，IBM将AFS 3.6版公开发布，作为开放源代码软件称为OpenAFS，但IBM仍然拥有AFS。OpenAFS被公开发布之后，一度影响了NFSv4的开发。
所谓分布式文件系统，主要有两方面的含义：
其一：采用分布式结构的文件系统与传统的集中式的文件系统相比，AFS的各个组件能够分布在网络中的不同机器上，并通过一定的机制协同工作。它并不是简单地C/S(客户端/服务器)结构，也并不象C/S结构的客户端那样仅为服务器端提供接口，所有的功能都集中在服务器端。AFS的各个组件都能够独立的完成某种功能，同时这些组件在一定的机制协调下，又形成一个完整的系统；
其二：AFS是一种能够管理分布式文件数据的文件系统，它不但可以把分布在不同网络节点上的存储资源组织成一个虚拟的存储空间，而且能够提供跨平台的文件管理功能。
1、AFS的跨平台管理功能能够使用户方便、高效地共享分布在局域网或广域网中的文件。用户并不需要考虑文件保存在什么地方，也不用考虑文件保存在哪种操作系统上，AFS提供给用户的只是一个完全透明的、永远唯一的逻辑路径，通过这个逻辑路径，用户就象面对一个文件目录一样，这个目录下的内容无论是在什么地方访问，都绝对的一致。因此，AFS的这种功能往往被用于用户的home目录，以使得用户的home目录唯一、而且避免了数据的不一致性。
2、AFS是一种高安全性的文件系统。它通过鉴权数据库与ACL的配合为用户提供更高的安全性。用户使用AFS，首先需要验证身份，只有合法的AFS用户才能够访问相应的CELL(一个CELL就相当于一个AFS独立结构，该CELL具有AFS文件系统的全部功能)；其次，用户还需要在保护数据库中读取相应的ACL列表，以确定他是否有权力读写某一个文件。因此，AFS提供了更高于传统UNIX系统的安全性能。
3、AFS的目录结构是全球统一的。根据规定，AFS的前两级目录必须由"/afs/cellname"组成，其中，cellname可替换为不同单位的Cell名称。就组织的情况来说，已经定义了唯一的cell名：ihep.freeoa.net，并建立了唯一的前两级目录：/afs/ihep.freeoa.net/。因此，无论用户从什么地方去访问/afs/ihep.freeoa.net下的文件，都相当于访问了组织网络内部的资源。
AFS 是一个稳定的单元，其每个单元代表文件空间中一个独立的管理部分。单元连接在一起组成了一个在根 /afs 目录下的一个庞大的 UNIX 文件系统。与普通文件系统相比，AFS的主要特点在于三个方面：分布式、跨平台、高安全性。
AFS 文件系统重要概念
什么是 AFS 文件系统
这是一种分散式的文件系统 ( Distributed File System)能够将分散在不一样机器上磁盘空间组合成一个共有的磁盘空间，让使用者可以在不一样的机器上使用相同的文件系统来管理本身的文件。
AFS 的运行模式
AFS 采用 C/S (Client/Server) 的工做模式，Client 发送请求到 Server 提取文件，Server 提供文件给请求的 Client 。
当 Client 上的某个进程第一次须要某个文件资料时 ,Client 上的一个名叫 Cache Manager 的进程 ，便会负责找出存放有该文件的 Server( 会从 CellServ 配置文件中找到 VLDB 服务器，再经由 VLDB 找到相应文件存放的 Server)，使用 RPC 通讯协议来取回文件存储于本身的 Cache 中，以后就能够直接读写于 Cache 中的资料了，这期间 Cache Manager 会适时的和 Server 通讯来更新资料，有了 Cache Manager 的帮助使得网络的负荷减轻，由于当咱们读写一个在其余机器上的资料时，再也不须要每次都经由网络去读取，而由 Cache Manage 判断在 Cache 的资料是否和 Server 上所存的相同，若相同就直接使用 Cache 上的资料，如此一来节省了部分读取文件时所须要的传送，更减小了本来 Server 上的磁盘 I/O 负载。
OpenAFS 基本原理
OpenAFS 试图免除安装和管理用于使不一样文件系统合作的软件时的痛苦，也能使不一样文件系统更有效地合做。尽管 UNIX 及其引人注目的后继者 Plan 9 的最初目标是文件，可是商业现实指出，与其彻底重构现代的网络文件系统 ，不如添加另外一个分布式文件系统层 。
1983 年 Carnegie Mellon University 的编 程人员开发 了 AFS 。此后不久， 该大学成立了一家叫作 Transarc 的公司来出售基于 AFS 的服 务 。1998 年 IBM 收购了 Transarc ，并使 AFS 成为一个开放源码产品，叫作 OpenAFS 。可故事并未就此结束，因为 OpenAFS 衍生了其它的分布式文件系统 ，如 Coda 和 Arla 。 存在针对全部主要操做系统的各种客户机，及大量的过期文档资料。Gentoo 为使 OpenAFS 对 Linux 用户可用作出了特别贡献 。
OpenAFS 如何进行管理
NFS 是位置无关的，它把本地目录映射到远程文件系统位置。OpenAFS 对用户隐藏了文件位置。因为可能全部的源文件都以读写副本的形式保存在复制到的不一样文件服务器位置上，必须保持复制的副本同 步 。 为此要使用一项称做 Ubik 的技术 ，它源于单词 “ubiquitous (无所不在) ” ，是东欧拼写法。 Ubik 过程使 AFS 文件系统上的文件、目录和卷 (volume) 保持同步 ，可是一般运行三个以上文件服务器进程的系统获益最多。系统管理人员能够将一个 AFS 站点的几个 AFS cell 分组 —— 这个之前的缩写词 AFS 已 经被保留在 OpenAFS 文件系统的语义中了。 管理人员将决定 AFS cell 的数目，以及 cell 使存储器和文件对站点内的其余 AFS cell 可用的程度。
AFS 中的几个名词解释
Cell：一个管理单元，由一个 Group 或一个管理单位所负责管理的基本单元，一般是由许多文件及目录所组成的一个结构，不同的 Cell 能够组合成为一个 AFS File Space。一般是一个主服务器和几个附加服务器组成一个 Cell 每一个 Cell 共用本身的 VLDB 。
Partition：通常常使用电脑的人，对于硬盘上的 Partiton 必定不会陌生，对于一个分散文件系统而言，这个系统管理既然是文件，必会和硬盘扯上关系，使得 AFS 对于硬盘一样能够分 Partition ，可是 AFS 中的分区必须是 /vicepXX 这样的形式 XX 能够是 a-zz 中的任意组合或单个字母。
Volumes：在每一个 Partition 上能够再分更小的单元，咱们称之为 Volumes ，对于使用者而言，并不须要太注意 Volumes 究竟是作什么的，由于使用者使用 AFS ，只是想好好好使用本身的文件，而没必要要理会 Volume 或者 Partition ，这二者都只是 AFS 对于硬盘空间的管理，适用者所须要的 AFS 的系统管理都已经帮你做好了。
AFS 管理人员把 cell 划分为所谓的卷 。 虽然卷能够随硬盘分区协同扩展 (co-extensive) ，但大多数管理人 员 都不会将整个分区只分 为 一个卷。AFS 卷 实际 上是由一个单 独的、称做 Volume Manager 的 UNIX 类型的进程管理的。能够以一 种常见的方式从 UNIX 文件系统目录安装卷。可是，能够将 AFS 卷从一个文件服务器移动到另外一个文件服务器 —— 同样是由一个 UNIX 类型的进程来管理的 —— 可是 UNIX 目录不能从一个分区实际地移动到另外一个分区上。 AFS 通 过 Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录 。所以每当文件服务器非预期地中止操做，用户根本无需担忧，因为 AFS 会把用户切换到另外一个文件服务器机器上的复制卷，而用户可能都不会注意到。
用户历来不对 AFS 服务器上的文件进行操做。他们操做已经由客户端缓存管理器从文件服务器中取出的文件。 Cache Manager 是留在客户机操做系统内核中的一只很是有趣的猛兽(可在 2.4 版本以上的任何内核中运行 Cache Manager )。
Mount Point：分散文件系统的最大特点是，不须要专门的指定一部机器做为文 件的存储，相反的，任何一部机器均可以使存储文件的 Server ，也能够成为提出要求存取某个文件的 Client ，那么文件都分散存储在不一样的机器上，使用者要如何存取它所须要的文件呢？
前面提过 Volume 的概念，让咱们从 Volume 的概念出发，各位能够将 Volume 视作一个箱子，负责存一个目录文 件，当你下达了 cd 命令更换目前所在的目录，有两种状况会发生，第一种状况是，所更换的目录仍在同一个 Volume ，第二种状况是，须要换到另外一个 Volume 中，此时便须要一个指标来指示， 所要更换的目录是在哪个 Volume ，好到该 Volume 所在处取出该 Volume 的资料，这个指标便成为 Mount Points。
简单一点来讲， AFS 系统是利用 Mount Points 的概念，不漏痕迹的取回使用者所须要的文件或目录资料。
CacheManager：Cache Manager 能够响应本地应用程序的请 求，来跨 AFS 文件系统取出文件。固然，若是该文件是经常更改的源文件，那么文件存在于几个复制版本中可能不太好。因为用户极可能要频繁地更改经常被请求的源文件，因此会遇到两个问题：首先，文件极可能被保存在客户机缓存内，而同时还保存在几个文件服务器机器上的几个复制卷内；而后，Cache Manager 不得不更新全部的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统能够处理发生在其余地方的任何更改。若是用户更改了缓存在其余地方的复制文件，原始文件服务器将会激活回 调 ，并提醒原始缓存版本它须要更新。
分布式版本控制系统也面临这个经典问题 ，可是有一点重要的区 别 ：分布式版本控制系统在断开时能够运行得很好，而 AFS 文件系统的任一部分都不能断开 。断开的 AFS 部分没法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的 AFS 文件服务器重新同步，可是不能添加可能在它断开后保存在本地的新更改。
AFS vs NFS
Andrew File System，最初是由CMU和IBM联合开发的分布式文件系统。按照在NFS中所说的系统最重要的是要先看它的目标是什么，对于AFS来说，目标只有一个大规模[large scale]。也就是说一个server能支持愈多的client越好。
回顾一下NFS的特点，其中一个就是客户端要不停地和服务器交互以确定当前适用的文件是最新的，这种情况下，越多的客户端必然造成更大的网络开销和更频繁的客户端-服务器交互，以至于在达到一定客户端数量后服务器就不能再支持更多的客户端。所以这里一点个人思考就是，在单服务器多客户端的环境下，要想保证large scale就要最大限度的减少服务器-client之间的交互，同时为了保证系统的可靠性，服务器应该最小限度的保存最重要的信息。
基于large scale的定位，AFS有着和NFS截然不同的架构。
回调
首先，不同于NFS中客户端要频繁的检查服务器的文件状态，AFS提供了回调机制，AFS会记录每个客户端都读取并缓存了那些文件，一旦一个文件被一个客户端修改并更新到服务器，服务器会回调所有拥有这个文件的其他客户端，告诉他们这个文件已经过期，请更新。如此就避免了多次客户端向服务器询问或请求文件的过程。
全文件缓存
另外一个巨大区别是，NFS是通过文件句柄逐步获得请求文件，AFS则是将所有文件统统缓存到客户端，这样客户端也不用频繁的获取文件，因为几乎所有文件都在本地。具体说来是，当客户端请求/root/doc/foo.txt的时候，AFS会把root文件夹所有文件给客户端(这里使用文件描述符)并建立对应的回调，然后再把doc路径下所有文件都给客户端并建立回调，这样如果客户端以后需要请求任何在root目录下的文件，都不需要再请求服务器而可以直接进行本地操作。同时，因为建立的对应的回调机制，任何一个文件的修改，服务器都会通知客户端，并要求其进行更新操作。
一致性
如同前文所述，一致性主要通过回调机制实现。同时需要注意的是，AFS采用最后一个成功写(last writer win)机制，也就是，当不同客户端同时修改了一个文件并更新到服务器，那么服务器会采用最后一个更新，也就是说之前所有其它客户端的更新会被最后一个更新覆盖。这里也和NFS不同，因为AFS的一致性是文件级别所以最后的更新就是服务器文件的最终状态，但是NFS提供的是block-based protocol，所以一个文件的最终状态可能是不同客户端的几次不同更新的混合。
崩溃恢复
因为AFS的设计目标并不是以恢复为重要功能，所以这方面AFS要远逊色于NFS。尤其是当服务器崩溃之后，恢复的工作是非常复杂的，因为服务器存储了很多状态信息，客户端必须能够知道服务器什么时候崩溃的，然后和服务器进行交互来恢复到之前的状态信息。具体的实现方式可以有很多，但是基本的设计理念就是如此。
NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步：
无状态系统
在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统。
回调(Callback)系统
在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回调应答(ca11backpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回调系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回调并通知这些改变。
无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回调。客户机检查回调应答中的时间期限以保证回调应答是当前有效的。回调应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回调应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。
DCE分散式档案系统
开放软件基金会在开发分布式运算环境时，其中的DCE分布式文件系统也是源自安德鲁文件系统的一个分支。 DCE分散式档案系统(英语：DCE Distributed File System，缩写为DCE/DFS)，一种分散式档案系统，使用于分散式运算环境(DCE)中。它的核心是一套远端档案存取的网络协定，基于Transarc公司开发的安德鲁档案系统第三版(AFS-3)网络协定发展而成，它最早起源于卡内基梅隆大学开发的安德鲁档案系统。2000年时，IBM公司公布OpenAFS时，也对外公开释出这个协定的文件；但在2005年之后，IBM公司已经不再继续维护这套标准，转而开发先进分散式档案系统(Advanced Distributed File System，ADFS)。
这套协定由开放软件社区继续发展。1989年，开放软件基金会开发的分散式运算环境，采用了这套系统，作为它的一部分，并以LGPL协议释出。
Firefox和GNOME最终可以在Linux 5.2的AFS文件系统上运行
2019年5月，AFS现在可以处理更多运行在Firefox和GNOME等文件系统之上的程序。到目前为止，AFS文件锁定已经导致SQLite数据库出现问题，Firefox和无数其他桌面应用程序都在多个平台上使用SQLite数据库。随着Linux 5.2内核的更改，AFS文件锁定更改现在与SQLite一致，因此当AFS用作主目录时，可以运行更多的应用程序。这些AFS的更改之前曾被提议用于Linux 5.1，但最终被Linus Torvalds拒绝为“未经测试的新垃圾”。现在代码已被清理，并已由Torvalds拉入主线。
此实现需要模拟细粒度锁定，并且可以将行为作为挂载参数进行切换。Linux 5.2的其他AFS更改包括额外的日志记录、为unlock()和rename()重命名、修复xattr处理程序和其他修复。更多关于Andrew文件系统可以查看这个pull request可获得更多的细节。
最新版本：1.9
官方主页：https://openafs.org/
AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for federated file sharing and replicated read-only content distribution, providing location independence, scalability, security, and transparent migration capabilities. AFS is available for a broad range of heterogeneous systems including UNIX, Linux, MacOS X, and Microsoft Windows.
IBM branched the source of the AFS product, and made a copy of the source available for community development and maintenance. They called the release OpenAFS.
1987年，卡内基梅隆大学由AFS-2中，分支出Coda，主要是使用于笔记本电脑上。1989年，Transarc公司获取AFS的商业性开发权利，开始销售AFS，提供商业使用。1993年，瑞典皇家工学院利用AFS的分支，开发了Arla。1994年，IBM并购了Transarc公司，同时也得到这套软件。2000年8月，IBM将AFS 3.6版公开发布，作为开放源代码软件称为OpenAFS，但IBM仍然拥有AFS。OpenAFS被公开发布之后，一度影响了NFSv4的开发。
所谓分布式文件系统，主要有两方面的含义：
其一：采用分布式结构的文件系统与传统的集中式的文件系统相比，AFS的各个组件能够分布在网络中的不同机器上，并通过一定的机制协同工作。它并不是简单地C/S(客户端/服务器)结构，也并不象C/S结构的客户端那样仅为服务器端提供接口，所有的功能都集中在服务器端。AFS的各个组件都能够独立的完成某种功能，同时这些组件在一定的机制协调下，又形成一个完整的系统；
其二：AFS是一种能够管理分布式文件数据的文件系统，它不但可以把分布在不同网络节点上的存储资源组织成一个虚拟的存储空间，而且能够提供跨平台的文件管理功能。
1、AFS的跨平台管理功能能够使用户方便、高效地共享分布在局域网或广域网中的文件。用户并不需要考虑文件保存在什么地方，也不用考虑文件保存在哪种操作系统上，AFS提供给用户的只是一个完全透明的、永远唯一的逻辑路径，通过这个逻辑路径，用户就象面对一个文件目录一样，这个目录下的内容无论是在什么地方访问，都绝对的一致。因此，AFS的这种功能往往被用于用户的home目录，以使得用户的home目录唯一、而且避免了数据的不一致性。
2、AFS是一种高安全性的文件系统。它通过鉴权数据库与ACL的配合为用户提供更高的安全性。用户使用AFS，首先需要验证身份，只有合法的AFS用户才能够访问相应的CELL(一个CELL就相当于一个AFS独立结构，该CELL具有AFS文件系统的全部功能)；其次，用户还需要在保护数据库中读取相应的ACL列表，以确定他是否有权力读写某一个文件。因此，AFS提供了更高于传统UNIX系统的安全性能。
3、AFS的目录结构是全球统一的。根据规定，AFS的前两级目录必须由"/afs/cellname"组成，其中，cellname可替换为不同单位的Cell名称。就组织的情况来说，已经定义了唯一的cell名：ihep.freeoa.net，并建立了唯一的前两级目录：/afs/ihep.freeoa.net/。因此，无论用户从什么地方去访问/afs/ihep.freeoa.net下的文件，都相当于访问了组织网络内部的资源。
AFS 是一个稳定的单元，其每个单元代表文件空间中一个独立的管理部分。单元连接在一起组成了一个在根 /afs 目录下的一个庞大的 UNIX 文件系统。与普通文件系统相比，AFS的主要特点在于三个方面：分布式、跨平台、高安全性。
AFS 文件系统重要概念
什么是 AFS 文件系统
这是一种分散式的文件系统 ( Distributed File System)能够将分散在不一样机器上磁盘空间组合成一个共有的磁盘空间，让使用者可以在不一样的机器上使用相同的文件系统来管理本身的文件。
AFS 的运行模式
AFS 采用 C/S (Client/Server) 的工做模式，Client 发送请求到 Server 提取文件，Server 提供文件给请求的 Client 。
当 Client 上的某个进程第一次须要某个文件资料时 ,Client 上的一个名叫 Cache Manager 的进程 ，便会负责找出存放有该文件的 Server( 会从 CellServ 配置文件中找到 VLDB 服务器，再经由 VLDB 找到相应文件存放的 Server)，使用 RPC 通讯协议来取回文件存储于本身的 Cache 中，以后就能够直接读写于 Cache 中的资料了，这期间 Cache Manager 会适时的和 Server 通讯来更新资料，有了 Cache Manager 的帮助使得网络的负荷减轻，由于当咱们读写一个在其余机器上的资料时，再也不须要每次都经由网络去读取，而由 Cache Manage 判断在 Cache 的资料是否和 Server 上所存的相同，若相同就直接使用 Cache 上的资料，如此一来节省了部分读取文件时所须要的传送，更减小了本来 Server 上的磁盘 I/O 负载。
OpenAFS 基本原理
OpenAFS 试图免除安装和管理用于使不一样文件系统合作的软件时的痛苦，也能使不一样文件系统更有效地合做。尽管 UNIX 及其引人注目的后继者 Plan 9 的最初目标是文件，可是商业现实指出，与其彻底重构现代的网络文件系统 ，不如添加另外一个分布式文件系统层 。
1983 年 Carnegie Mellon University 的编 程人员开发 了 AFS 。此后不久， 该大学成立了一家叫作 Transarc 的公司来出售基于 AFS 的服 务 。1998 年 IBM 收购了 Transarc ，并使 AFS 成为一个开放源码产品，叫作 OpenAFS 。可故事并未就此结束，因为 OpenAFS 衍生了其它的分布式文件系统 ，如 Coda 和 Arla 。 存在针对全部主要操做系统的各种客户机，及大量的过期文档资料。Gentoo 为使 OpenAFS 对 Linux 用户可用作出了特别贡献 。
OpenAFS 如何进行管理
NFS 是位置无关的，它把本地目录映射到远程文件系统位置。OpenAFS 对用户隐藏了文件位置。因为可能全部的源文件都以读写副本的形式保存在复制到的不一样文件服务器位置上，必须保持复制的副本同 步 。 为此要使用一项称做 Ubik 的技术 ，它源于单词 “ubiquitous (无所不在) ” ，是东欧拼写法。 Ubik 过程使 AFS 文件系统上的文件、目录和卷 (volume) 保持同步 ，可是一般运行三个以上文件服务器进程的系统获益最多。系统管理人员能够将一个 AFS 站点的几个 AFS cell 分组 —— 这个之前的缩写词 AFS 已 经被保留在 OpenAFS 文件系统的语义中了。 管理人员将决定 AFS cell 的数目，以及 cell 使存储器和文件对站点内的其余 AFS cell 可用的程度。
AFS 中的几个名词解释
Cell：一个管理单元，由一个 Group 或一个管理单位所负责管理的基本单元，一般是由许多文件及目录所组成的一个结构，不同的 Cell 能够组合成为一个 AFS File Space。一般是一个主服务器和几个附加服务器组成一个 Cell 每一个 Cell 共用本身的 VLDB 。
Partition：通常常使用电脑的人，对于硬盘上的 Partiton 必定不会陌生，对于一个分散文件系统而言，这个系统管理既然是文件，必会和硬盘扯上关系，使得 AFS 对于硬盘一样能够分 Partition ，可是 AFS 中的分区必须是 /vicepXX 这样的形式 XX 能够是 a-zz 中的任意组合或单个字母。
Volumes：在每一个 Partition 上能够再分更小的单元，咱们称之为 Volumes ，对于使用者而言，并不须要太注意 Volumes 究竟是作什么的，由于使用者使用 AFS ，只是想好好好使用本身的文件，而没必要要理会 Volume 或者 Partition ，这二者都只是 AFS 对于硬盘空间的管理，适用者所须要的 AFS 的系统管理都已经帮你做好了。
AFS 管理人员把 cell 划分为所谓的卷 。 虽然卷能够随硬盘分区协同扩展 (co-extensive) ，但大多数管理人 员 都不会将整个分区只分 为 一个卷。AFS 卷 实际 上是由一个单 独的、称做 Volume Manager 的 UNIX 类型的进程管理的。能够以一 种常见的方式从 UNIX 文件系统目录安装卷。可是，能够将 AFS 卷从一个文件服务器移动到另外一个文件服务器 —— 同样是由一个 UNIX 类型的进程来管理的 —— 可是 UNIX 目录不能从一个分区实际地移动到另外一个分区上。 AFS 通 过 Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录 。所以每当文件服务器非预期地中止操做，用户根本无需担忧，因为 AFS 会把用户切换到另外一个文件服务器机器上的复制卷，而用户可能都不会注意到。
用户历来不对 AFS 服务器上的文件进行操做。他们操做已经由客户端缓存管理器从文件服务器中取出的文件。 Cache Manager 是留在客户机操做系统内核中的一只很是有趣的猛兽(可在 2.4 版本以上的任何内核中运行 Cache Manager )。
Mount Point：分散文件系统的最大特点是，不须要专门的指定一部机器做为文 件的存储，相反的，任何一部机器均可以使存储文件的 Server ，也能够成为提出要求存取某个文件的 Client ，那么文件都分散存储在不一样的机器上，使用者要如何存取它所须要的文件呢？
前面提过 Volume 的概念，让咱们从 Volume 的概念出发，各位能够将 Volume 视作一个箱子，负责存一个目录文 件，当你下达了 cd 命令更换目前所在的目录，有两种状况会发生，第一种状况是，所更换的目录仍在同一个 Volume ，第二种状况是，须要换到另外一个 Volume 中，此时便须要一个指标来指示， 所要更换的目录是在哪个 Volume ，好到该 Volume 所在处取出该 Volume 的资料，这个指标便成为 Mount Points。
简单一点来讲， AFS 系统是利用 Mount Points 的概念，不漏痕迹的取回使用者所须要的文件或目录资料。
CacheManager：Cache Manager 能够响应本地应用程序的请 求，来跨 AFS 文件系统取出文件。固然，若是该文件是经常更改的源文件，那么文件存在于几个复制版本中可能不太好。因为用户极可能要频繁地更改经常被请求的源文件，因此会遇到两个问题：首先，文件极可能被保存在客户机缓存内，而同时还保存在几个文件服务器机器上的几个复制卷内；而后，Cache Manager 不得不更新全部的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统能够处理发生在其余地方的任何更改。若是用户更改了缓存在其余地方的复制文件，原始文件服务器将会激活回 调 ，并提醒原始缓存版本它须要更新。
分布式版本控制系统也面临这个经典问题 ，可是有一点重要的区 别 ：分布式版本控制系统在断开时能够运行得很好，而 AFS 文件系统的任一部分都不能断开 。断开的 AFS 部分没法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的 AFS 文件服务器重新同步，可是不能添加可能在它断开后保存在本地的新更改。
AFS vs NFS
Andrew File System，最初是由CMU和IBM联合开发的分布式文件系统。按照在NFS中所说的系统最重要的是要先看它的目标是什么，对于AFS来说，目标只有一个大规模[large scale]。也就是说一个server能支持愈多的client越好。
回顾一下NFS的特点，其中一个就是客户端要不停地和服务器交互以确定当前适用的文件是最新的，这种情况下，越多的客户端必然造成更大的网络开销和更频繁的客户端-服务器交互，以至于在达到一定客户端数量后服务器就不能再支持更多的客户端。所以这里一点个人思考就是，在单服务器多客户端的环境下，要想保证large scale就要最大限度的减少服务器-client之间的交互，同时为了保证系统的可靠性，服务器应该最小限度的保存最重要的信息。
基于large scale的定位，AFS有着和NFS截然不同的架构。
回调
首先，不同于NFS中客户端要频繁的检查服务器的文件状态，AFS提供了回调机制，AFS会记录每个客户端都读取并缓存了那些文件，一旦一个文件被一个客户端修改并更新到服务器，服务器会回调所有拥有这个文件的其他客户端，告诉他们这个文件已经过期，请更新。如此就避免了多次客户端向服务器询问或请求文件的过程。
全文件缓存
另外一个巨大区别是，NFS是通过文件句柄逐步获得请求文件，AFS则是将所有文件统统缓存到客户端，这样客户端也不用频繁的获取文件，因为几乎所有文件都在本地。具体说来是，当客户端请求/root/doc/foo.txt的时候，AFS会把root文件夹所有文件给客户端(这里使用文件描述符)并建立对应的回调，然后再把doc路径下所有文件都给客户端并建立回调，这样如果客户端以后需要请求任何在root目录下的文件，都不需要再请求服务器而可以直接进行本地操作。同时，因为建立的对应的回调机制，任何一个文件的修改，服务器都会通知客户端，并要求其进行更新操作。
一致性
如同前文所述，一致性主要通过回调机制实现。同时需要注意的是，AFS采用最后一个成功写(last writer win)机制，也就是，当不同客户端同时修改了一个文件并更新到服务器，那么服务器会采用最后一个更新，也就是说之前所有其它客户端的更新会被最后一个更新覆盖。这里也和NFS不同，因为AFS的一致性是文件级别所以最后的更新就是服务器文件的最终状态，但是NFS提供的是block-based protocol，所以一个文件的最终状态可能是不同客户端的几次不同更新的混合。
崩溃恢复
因为AFS的设计目标并不是以恢复为重要功能，所以这方面AFS要远逊色于NFS。尤其是当服务器崩溃之后，恢复的工作是非常复杂的，因为服务器存储了很多状态信息，客户端必须能够知道服务器什么时候崩溃的，然后和服务器进行交互来恢复到之前的状态信息。具体的实现方式可以有很多，但是基本的设计理念就是如此。
NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步：
无状态系统
在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统。
回调(Callback)系统
在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回调应答(ca11backpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回调系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回调并通知这些改变。
无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回调。客户机检查回调应答中的时间期限以保证回调应答是当前有效的。回调应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回调应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。
DCE分散式档案系统
开放软件基金会在开发分布式运算环境时，其中的DCE分布式文件系统也是源自安德鲁文件系统的一个分支。 DCE分散式档案系统(英语：DCE Distributed File System，缩写为DCE/DFS)，一种分散式档案系统，使用于分散式运算环境(DCE)中。它的核心是一套远端档案存取的网络协定，基于Transarc公司开发的安德鲁档案系统第三版(AFS-3)网络协定发展而成，它最早起源于卡内基梅隆大学开发的安德鲁档案系统。2000年时，IBM公司公布OpenAFS时，也对外公开释出这个协定的文件；但在2005年之后，IBM公司已经不再继续维护这套标准，转而开发先进分散式档案系统(Advanced Distributed File System，ADFS)。
这套协定由开放软件社区继续发展。1989年，开放软件基金会开发的分散式运算环境，采用了这套系统，作为它的一部分，并以LGPL协议释出。
Firefox和GNOME最终可以在Linux 5.2的AFS文件系统上运行
2019年5月，AFS现在可以处理更多运行在Firefox和GNOME等文件系统之上的程序。到目前为止，AFS文件锁定已经导致SQLite数据库出现问题，Firefox和无数其他桌面应用程序都在多个平台上使用SQLite数据库。随着Linux 5.2内核的更改，AFS文件锁定更改现在与SQLite一致，因此当AFS用作主目录时，可以运行更多的应用程序。这些AFS的更改之前曾被提议用于Linux 5.1，但最终被Linus Torvalds拒绝为“未经测试的新垃圾”。现在代码已被清理，并已由Torvalds拉入主线。
此实现需要模拟细粒度锁定，并且可以将行为作为挂载参数进行切换。Linux 5.2的其他AFS更改包括额外的日志记录、为unlock()和rename()重命名、修复xattr处理程序和其他修复。更多关于Andrew文件系统可以查看这个pull request可获得更多的细节。
最新版本：1.9
官方主页：https://openafs.org/