实现一个文件系统——目标

现有的文件系统已经千千万万，为什么还要做这么一件奇怪的事情，说起来原因也是非常奇怪的。有一天BOSS来告诉我，要对原始COUNTER进行备份管理，让我考虑一下设计方案。当然首先自然先了解一下大致的需求，结果使得这件事情变得比较有意思：

一般原始COUNTER一般都是一些文本文件，但是文件量比较大，每天可产生约1T的数据，数亿个文件，可能需要保存数年的数据。那么也就是需要提供PB级别的服务罗。如果只是简单的备份那也罢了，可能的话，最好能够随时提取对这些文件中的一个或者一批进行读取。

后来证明但是的这个交流中将量级整个的搞错了，每天的文件个数大约是20W左右而不是2亿，文件总量是200M而不是1T，需求整整降低了一个数量级别。然而，那时候我已经开始按照原来的要求，走了很远了……

对于这样一个需求，首先想到的自然是要压缩，这个级别的总量，需要10-100：1的压缩比存储，否则对于存储系统本身就是一个太高的要求。其次是要打包，简单分析就知道，需要管理的文件数量总量虽然很大，但是平均每个文件的大小都非常的小，大部分文件的大小只有几K左右，压缩后一般会小于1K，大量的这种小文件，如果单个文件保存的话，一个文件往往都填不满一个扇区，浪费的这些空间总量也不是一个小数目了。此外文件数据量达到数十亿时，对操作系统的文件系统本身也会产生太大的压力。

考察了一遍，各种压缩文件都不能提供很好的随机访问的特性，当压缩包本身已经足够大的时候，向压缩包中追加文件一般也非常的慢。另外如ZFS，CROMF等一些压缩文件系统，基本xnux系统下的，需要特定的环境，追加文件也是一个比较麻烦的事情。

只能自己做一个了，大致的想法就是将数个文件压缩存储到一个大文件中，维持一个索引，能够快速的定位某一个文件在压缩包的位置并提取出来。因此这样一个文件系统的设计目标，大致就清楚了：

 * 需要管理海量的数据文件，文件个数在数 G 至数 T 级别

 * 每个文件的基本都很小，一般就几K，且文件具有很好的可压缩性

 * 需要管理文件总量在 TB 至 PB 级别

 * 这些文件绝大部分都是只读的，一般情况下写入以后就不再修改，但不排除偶尔进行修改的可能，只是几率非常的小

 * 需要对文件系统的文件进行随机提取，一般对文件的访问方式是顺序的读取整个文件内容，几乎可以不考虑随机位置读取的问题。

 * 提取文件的性能要求有高吞吐量，可能将会有数千个并发读取操作。

 * 文件的业务价值并不高，因此不要希望于有很强大的硬件平台支持，可用的服务器可能就是几台普通PC，多挂几块硬盘而已。

 * 尽量提供较高的压缩比

 * 要有较好的跨平台性，至少应该能够支持 Windows 以及 Linux