LFS[Log-structured File System]也是由Berkeley的研究人员最先提出并实现的，他们当时认为随机I/O和顺序I/O之间存在着巨大性能差异，其实就是顺序I/O快，随机I/O慢[因为要磁盘需要seek和rorate的时间]。所以说随机I/O成了bottleneck拖了后腿。但是记得在介绍FFS的blog中说过，即便在FFS中，一个write操作其实是至少5次write操作，因为写入一个data block还要更新对应的metadata信息，这里面就比不可少的需要随机I/O。要是能够只用顺序读写就好了，可以大幅度提高I/O效率了。同时Berkeley的研究人员还认为write操作占据了全部操作的很大一部分，因为Memory在快速增长，能够Cache的数据也越来越多那么就要涉及更多的write操作。所以基于这样两个考虑：(1)write占所有disk操作大部分；(2)随机IO性能比连续IO差很多，要是能只用连续I/O就会大幅度提高性能，LFS不更新任何数据只提供append[追加]操作，同时会建立buffer将多次操作放进一个segment里一次性写入来有效利用顺序IO。

Fast File System，快速文件系统，是由Berkeley大学研究人员设计并实现的建立在UNIX操作系统的一套文件系统。这个系统主要目标已经体现在它的名字上，就是建立一个快速的文件系统。因为他们发现之前的UNIX的文件系统（参考之前的Blog文章“Concepts of Unix File System”）在性能方面存在问题，主要问题是在磁头定位，位置转化过程中浪费了大量的时间，导致效率不高。所以FFS的一大设计思路就是降低磁头的seek时间，而解决方案也很简单，keep related stuff together，这样seek的时候就可以节省时间。整个FFS涉及几个关键概念

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

NFS最初是由Sun Microsystems公司提出，全名Sun Network Filesystem，旨在提供一个独立于机器和操作系统的能够快速从错误（crash，failure）中恢复的分布式文件系统。任何系统都要从这个系统的定位来看，也就是这个系统要达到什么目标。提出NFS的论文Design and Implemenatation of the Sun Network Fielsystem阐明，主要目标有五个：

Priority inversion[优先级反转，或者优先级翻转]，单从字面理解可能会认为是CPU调度线程的时候，两个线程的优先级互换，这个理解也是我第一次听到这个词的想法，但是和真实意思相去甚远，写在这里，也是提醒自己凡事不要想当然。

首先明确一点，分布式文件系统比如NFS，AFS，还有GFS与现在流行的分布式版本控制系统比如svn，git不同[主要在并发操作和同步异步机制上的区别]。简而言之，分布式版本控制系统构建在分布式文件系统之上，文件系统只完基本的同步和并发操作，相当于API，然后版本控制系统再指定自己的详细逻辑来处理并发和同步问题，弄清这点，才能理解为什么文件系统并不纠结与处理复杂的并发和同步操作。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同，比如客户端的一个重新连接函数，它可以不断执行直到成功连接上服务器，多次执行连接函数不会影响服务器的状态。但是客户端的对server的append操作就不是idempotent operation，因为每一次append操作都会对server进行修改从而改变server的状态。这个概念在分布式系统中发挥很大作用。

在介绍Unix文件系统之前先来介绍一下机械硬盘的典型构造中的基本概念[在unix问世的时代，还没有SSD]，机械硬盘主体是由多个圆形硬盘盘所组成的，依据硬盘盘能够容纳的数据量，而有所谓的单碟(一块硬盘里面只有一个硬盘盘)或者是多碟(一块硬盘里面含有多个硬盘盘)的硬盘，一般情况下都是多碟。