Andrew File System，最初是由CMU和IBM联合开发的分布式文件系统。按照在NFS中说的，系统最重要的是要先看它的目标是什么，对于AFS来说，目标只有一个large scale[大规模]。也就是说一个server能支持愈多的client越好。

回想一下NFS的特点，其中一个就是client要不停地和server交互以确定当前适用的文件是最新的，这种情况下，越多的client必然造成更大的网络开销和更频繁的client-server交互，以至于在达到一定client数量后server就不能再支持更多的client。所以这里一点个人思考就是，在single-server-muliple-clients的环境下，要想保证large scale就要最大限度的减少server-client之间的交互，同时为了保证系统的可靠性，server应该最小限度的保存最重要的信息。

基于large scale的定位，AFS有着和NFS截然不同的架构。

Callback

首先，不同于NFS中client要频繁的checkserver的文件状态，AFS提供了callback机制，AFS会记录每个client都读取并cache了那些文件，一旦一个文件被一个client修改并update到server，server会callback所有拥有这个文件的其他client，告诉他们这个文件已经过期，请更新。如此就避免了多次client向server询问或请求文件的过程。

Whole-file Caching

另外一个巨大区别是，NFS是通过file handle逐步获得请求文件，AFS则是将所有文件统统cache到client，这样client也不用频繁的获取文件，因为几乎所有文件都在本地。具体说来是，当client请求/root/doc/foo.txt的时候，AFS会把root文件夹所有文件给client（这里使用file identifier）并建立对应的callback，然后再把doc路径下所有文件都给client并建立callback，这样如果client以后需要请求任何在root目录下的文件，都不需要再请求server而可以直接进行本地操作。同时，因为建立的对应的callback，任何一个文件的修改，server都会通知client，并要求其进行更新操作。

Consistency

如同前文所述，consistency主要通过callback机制实现。同时需要注意的是，AFS采用last writer win机制，也就是，当不同client同时修改了一个文件并update到server，那么server会采用最后一个更新，也就是说之前所有其它client的update会被最后一个update覆盖。这里也和NFS不同，因为AFS的consistency是文件级别所以最后的update就是server文件的最终状态，但是NFS提供的是block-based protocol，所以一个文件的最终状态可能是不同client的几次不同update的混合。

Crash Recovery

因为AFS的设计目标并不是recovery，所以这方面AFS要远逊色于NFS。尤其是当server crash之后，恢复的工作是非常复杂的，因为server存储了很多状态信息，client必须能够知道server什么时候crash的，然后和server进行交互来恢复server之前的状态信息。具体的实现方式可以有很多，但是basic idea就是如此。