转自：http://blog.chinaunix.net/u/13229/showart_270314.html
AFS文件系统学习笔记
●什么是AFS文件系统？
.AFS是Andrew File System的缩写，他是一种分散式的文件系统(Distributed File System）可以将分散在不同机器上磁盘空间组合成一个共有的磁盘空间，让使用者能够在不同的机器上使用相同的文件系统来管理自己的文件.
●AFS的运行模式
.AFS采用C/S(Client/Server)的工作模式,Client发送请求到Server提取文件,Server Machine提供文件给请求的Client。
当Client Machine上的某个Porcess第一次需要某个文件资料时,Client Machine上的一个名叫Cache Manager的Process，便会负责找出存放有该文件的Server(他会从CellServ配置文件中找到 VLDB服务器，在经由VLDB找到相应文件存放的Server), 使用RPC通信协议来取回文件存储于自己的Cache中，之后就可以直接读写于Cache中的资料了，这期间Cache Manager会适时的和Server Machine通信来更新资料，有了Cache Manager的帮助使得网络的负荷减轻，因为当我们读写一个在其他机器上的资料时，不再需要每次都经由网络去读取，而由Cache Manage判断在Cache的资料是否和Server Machine上所存的相同，若相同，就直接使用Cache上的资料, 如此一来 节省了部分读取文件时所需要的传送，更减少了原本Server上的磁盘I/O负荷。
●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 如何进行管理
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的体系结构
●AFS分布式文件系统计算环境
