突然感觉艺术细胞爆发啊，刚刚去Utown吃饭，一路上发现许多美丽的景色，拿手机一直拍，哈哈，元旦好心情~~不扯淡，还有两篇博客以及半本书要做呢，加油！！
##1. 本文介绍什么
这篇博客介绍的是Andrew File System(**AFS**)，跟上一篇的[NFS](http://xubenbenhit.github.io/nfs.html)是同一类型的，都是[分布式文件系统](http://xubenbenhit.github.io/IntroToDistSystem.html)。
##2. AFS的设计目标
与NFS不同，AFS的设计目标是可扩展性，也就是说使得系统规模扩张，支持多的client等等。
##3. 设计思想
在单server多client的架构下，要**增强系统可扩展性主要就是要减轻server的负担，通过设计为server减负**成了设计主要目的。
那么首先来看NFS，文件的读写每次都要由client向server发出请求，然后才能操作，这对server是一个很大的负担，事实上根据局域性原理，很短的时间内被操作的文件很可能会被多次操作；其次，为了保持client端cache数据不至于过时，client需要每隔相对较短的时间（3秒）跟server同步一次信息，这也是一个很大的负担。
于是，**AFS**的改进也主要是从这而开始的。
**AFS**的解决方法是一种被称之为**whole-file caching**的方法，也就是说每次操作文件，就直接将整个文件从server端读出来然后存在本地磁盘中，这样后续的操作就可以在本地执行了，而不用server的参与。这减少了server的很多工作量。
对于第二个问题，**AFS**的做法是一种被称之为**call back**的方法，与其client过来问server某个文件是否过时（大多数情况都是没有过时），不如在文件过时的时候由server通知client。概括的来说就是，server知道各个client所缓存的文件，那么当一个文件被修改的时候，server通知client，这样下一次client需要操作这个文件的时候就不用缓存的数据了。
##4. 具体设计细节
- 命名空间
采用File identifier(**FID**)来标识文件，**FID**由三部分组成，卷标示符、文件标示符、以及一个"uniquifier"（这个东西是为了在文件删除的时候用来回收再利用卷标示符以及文件标示符的，就不展开了）
基本架构跟NFS是一样的的，还是这样:
- 完成的操作流程
为了便于描述，我们假设我们需要操作文件/home/remzi/notes.txt，见下图(其中的home FID就是目录"/home"的FID，可以认为是已知的):
- client 首先向server发出请求，以便获得文件夹remzi的FID，使用命令Fetch(home FID, "remzi")；
- server端收到请求后，寻找remezi文件夹，然后设置一个标志callback以便“记住”该client缓存的文件夹“memezi”的信息，最后返回文件夹remezi的FID以及文件夹的内容（文件夹也是一种“文件”）；
- client将remezi文件夹的内容存储在本地磁盘，并且在本地设置文件夹remezi的callback状态；
- 同样，client获得了文件foo.txt的FID、foo.txt的内容并且设置了callback状态，server也设置了文件foo.txt的callback；
- client对该文件执行read操作，则直接为转化为本地read操作；
- client关闭文件，此时检查文件是否被改变，如果被改变了，则将文件发给server以便更新server；否则，正常关闭即可。
- 假设client改变了文件内容并关闭文件了，则server接收到新的foo.txt之后更新到磁盘上的本地文件（也会更新cache，这个跟NFS一样的），同时通知缓存了文件foo.txt的client发出通知，修改client存储的foo.txt文件的callback状态；
- client再次打开文件foo.txt，则按照路径/home/remezi/foo.txt一步步检查callback状态，如果没有过时则继续在本地操作就可以了；否则，重复上面的过程。
此外，AFS做了一个修改，如果两个client在同一个机器上面，则client A修改文件，client B立刻就知到这个文件过时了。哈哈，就跟本地一样。
如果一个文件同时被两个client修改，那么怎么处理？哈哈，按照client关闭该文件的时间先后顺序，后关闭文件的那个client所做的修改被保存。这也确保了，每次文件修改都是由一个client完成的。
- 宕机
这个呢，AFS就有点麻烦了，毕竟client和server之间有了“共享信息”。具体而言，是这样：
- client 宕机
一旦client宕机然后重启，那么此时client就不相信任何存储在磁盘上的文件了，磁盘上的文件在client重启后第一次打开的时候需要跟server确认一下。
- server宕机
这个是一个很大的事故，因为server失去了跟client之间的“共享信息”，已经没有办法或者client在哪些文件上留下callback了。那么，一旦server宕机并重启，则所有client在磁盘上存储的文件/夹都被认为是可疑的，在server宕机重启后第一次打开，需要跟server确认一下，同时在server上重新留下callback。
这要求server重启后，每个client及时获知。一般而言可以server重启后向每个client发消息说明自己重启了。
##5. 参考文献
> 1.http://pages.cs.wisc.edu/~remzi/OSTEP/dist-afs.pdf
突然感觉艺术细胞爆发啊，刚刚去Utown吃饭，一路上发现许多美丽的景色，拿手机一直拍，哈哈，元旦好心情~~不扯淡，还有两篇博客以及半本书要做呢，加油！！
1. 本文介绍什么
这篇博客介绍的是Andrew File System(AFS)，跟上一篇的NFS是同一类型的，都是分布式文件系统。
2. AFS的设计目标
与NFS不同，AFS的设计目标是可扩展性，也就是说使得系统规模扩张，支持多的client等等。
3. 设计思想
在单server多client的架构下，要增强系统可扩展性主要就是要减轻server的负担，通过设计为server减负成了设计主要目的。
那么首先来看NFS，文件的读写每次都要由client向server发出请求，然后才能操作，这对server是一个很大的负担，事实上根据局域性原理，很短的时间内被操作的文件很可能会被多次操作；其次，为了保持client端cache数据不至于过时，client需要每隔相对较短的时间（3秒）跟server同步一次信息，这也是一个很大的负担。
于是，AFS的改进也主要是从这而开始的。
AFS的解决方法是一种被称之为whole-file caching的方法，也就是说每次操作文件，就直接将整个文件从server端读出来然后存在本地磁盘中，这样后续的操作就可以在本地执行了，而不用server的参与。这减少了server的很多工作量。
对于第二个问题，AFS的做法是一种被称之为call back的方法，与其client过来问server某个文件是否过时（大多数情况都是没有过时），不如在文件过时的时候由server通知client。概括的来说就是，server知道各个client所缓存的文件，那么当一个文件被修改的时候，server通知client，这样下一次client需要操作这个文件的时候就不用缓存的数据了。
4. 具体设计细节
- 命名空间
采用File identifier(FID)来标识文件，FID由三部分组成，卷标示符、文件标示符、以及一个"uniquifier"（这个东西是为了在文件删除的时候用来回收再利用卷标示符以及文件标示符的，就不展开了）
基本架构跟NFS是一样的的，还是这样:
完成的操作流程
为了便于描述，我们假设我们需要操作文件/home/remzi/notes.txt，见下图(其中的home FID就是目录"/home"的FID，可以认为是已知的):
- client 首先向server发出请求，以便获得文件夹remzi的FID，使用命令Fetch(home FID, "remzi")；
- server端收到请求后，寻找remezi文件夹，然后设置一个标志callback以便“记住”该client缓存的文件夹“memezi”的信息，最后返回文件夹remezi的FID以及文件夹的内容（文件夹也是一种“文件”）；
- client将remezi文件夹的内容存储在本地磁盘，并且在本地设置文件夹remezi的callback状态；
- 同样，client获得了文件foo.txt的FID、foo.txt的内容并且设置了callback状态，server也设置了文件foo.txt的callback；
- client对该文件执行read操作，则直接为转化为本地read操作；
- client关闭文件，此时检查文件是否被改变，如果被改变了，则将文件发给server以便更新server；否则，正常关闭即可。
- 假设client改变了文件内容并关闭文件了，则server接收到新的foo.txt之后更新到磁盘上的本地文件（也会更新cache，这个跟NFS一样的），同时通知缓存了文件foo.txt的client发出通知，修改client存储的foo.txt文件的callback状态；
- client再次打开文件foo.txt，则按照路径/home/remezi/foo.txt一步步检查callback状态，如果没有过时则继续在本地操作就可以了；否则，重复上面的过程。
此外，AFS做了一个修改，如果两个client在同一个机器上面，则client A修改文件，client B立刻就知到这个文件过时了。哈哈，就跟本地一样。
如果一个文件同时被两个client修改，那么怎么处理？哈哈，按照client关闭该文件的时间先后顺序，后关闭文件的那个client所做的修改被保存。这也确保了，每次文件修改都是由一个client完成的。
宕机
这个呢，AFS就有点麻烦了，毕竟client和server之间有了“共享信息”。具体而言，是这样：
- client 宕机
一旦client宕机然后重启，那么此时client就不相信任何存储在磁盘上的文件了，磁盘上的文件在client重启后第一次打开的时候需要跟server确认一下。
- server宕机
这个是一个很大的事故，因为server失去了跟client之间的“共享信息”，已经没有办法或者client在哪些文件上留下callback了。那么，一旦server宕机并重启，则所有client在磁盘上存储的文件/夹都被认为是可疑的，在server宕机重启后第一次打开，需要跟server确认一下，同时在server上重新留下callback。
这要求server重启后，每个client及时获知。一般而言可以server重启后向每个client发消息说明自己重启了。
5. 参考文献
1.http://pages.cs.wisc.edu/~remzi/OSTEP/dist-afs.pdf