不扯淡了，直接来写吧，一天一共要写三篇博客，还有两篇呢。
1. 这篇博客讲什么？
Fast File System(FFS)快速文件系统，基本思想已经在在上一篇博客 File System Implementation 里面说明了，FFS是对VSFS的一种优化改进使其可以被实际使用。
2. FFS基于VSFS的改进思想是什么？
这个呢，VSFS在存储文件的时候，根本没有考虑磁盘的寻址时间，把磁盘当做了一种随机存储介质！事实上由于局域性原理的存在，依据局域性而对存储做相应改进是非常有助于性能提升的。FFS则正是看到了这一点，其改进是将磁盘划分为多个子区域（Cylinder Groups），存储文件的时候同一文件夹下的文件尽可能放在同一个Group。Cylinder Groups是FFS最大的改进来源。
3. FFS文件系统的实现
-
首先，FFS将磁盘划分为很多子区域，也就是很多个Cylinder Groups，如下图：
每个组内的结构跟VSFS基本一样，下图：
对于这里面的SuperBlock每个组都会有。 -
文件存储 既然FFS号称利用局域性原理，那么具体是什么操作的呢？
- 对于文件夹，它会选择一个包含文件夹少而且剩余的空闲inode数目多的组来存储；
- 对于文件，它确保一个文件的inode和data是属于同一个组的；而且，将同一文件夹的文件尽量放在一个组，这里面的“尽量”是考虑到大文件可能需要被存在好几个组。
- 大文件 大文件是需要特殊处理的，因为否则的话因为组内空间被大文件大量占用，这就会使得很难实现“相关文件放一起”的那个使用局域性原理的设计。那么大文件就必须被“分割”为多块分别存储在各个组内，那么如何设定这个切割的大小呢，或者说大文件的每一块设置为多大。
这个需要一点计算。设置大文件切割大小核心在于，设置的太小了，那么读取它的时候影响效率（因为是需要额外寻址的，如果太小，这总的传输效率低）。假设磁盘的平均寻址时间是10ms，那么为了达到一半的传输效率，这意思是说磁盘真正用来传数据的时候和寻址时间相同，假设磁盘传输效率是40MB/s，那么10ms传输的数据是409.6KB。换句话说，只需要409KB，就可使的传输效率为50%。事实上，大约3.7MB就可使得磁盘平均传输效率为90%。所以，切割大小设置为4M左右就可以了。
FFS的设计者挺聪明的，其实按照之前的VSFS的设计，每个inode里面会有15个块指针用来索引文件占用磁盘块的，前面12个直接索引可表示12*4KB=48KB的空间，而一级间接索引就可表示4M的空间。所以除了前48KB，之后的每4M数据均放置在不同的组内，这个刚好可以使用一一级间接索引表示。
4. FFS设计细节
- 小文件问题 这个是说很多文件太小了，用一个磁盘块（4KB）存储有点浪费空间啊！！所以呢，FFS引入sub-blocks这个概念，一般是512B，也就是一个sector扇区的大小。那么这样一来又会使得写小文件的操作台低效了，哈哈，不用担心，我们可以写文件的时候现在Cache中缓存一下，等到收集了4KB的数据再一次性写入。这就是FFS提供的libc库的作用啦。
- parameterized placement 这个呢，有点难理解，先看这个图吧：
假设一个这个文斌就包含了12个磁盘块，而且如左边显示的那样存储于一个磁道上面。那么序列读取数据的时候就会有一个很小的问题：当磁头达到0块的时候读取数据，可是等它读完了准备读1块的数据的时候，磁头早就转过去了（假设转到2块的位置），于是需要接着等磁头转回来！！这样是不是很慢，事实上磁盘会将一个磁道的数据一下子缓存在磁盘里面，但是即使是这样，也需要两圈才能读完。因为你在等1快的数据的时候，磁盘转了一圈读出了整个磁道的数据，然后你获得了1块的数据，可是还是需要转一圈才能依次获得每一块的数据。于是乎就很聪明的将数据排列成右边那个样子，这样一来就只需要一圈啦。。。。
5. 参考文献
❝❞
- http://pages.cs.wisc.edu/~remzi/OSTEP/file-ffs.pdf