为什么会有文件系统
转自http://www.wowotech.net/author/529，感谢作者无私分享
<一>
Linux发展到现今，在fs目录下我们可以看到形形色色的文件系统，眼花缭乱的同时首先需要回答的问题是，为什么会有文件系统这个东西呢？我想如果能搞清楚这个问题，会帮助大家更好的理解文件系统，那么我就尝试着来模拟一次文件系统的演进过程，于是，我们来到了那一天，那天之前，人们还没有文件系统的概念。
友情提示 : 下面将在荒诞的场景下演进人类合理的诉求
神说，要有光，于是，光照大地
神说，要有风，于是，风动四方
神说，人类要记住神，于是，有了传说
神说，怕你们忘了，得记下来，于是，有了文字，信息被存储在石板上，竹片上，纸张上，硬盘里，flash中
当信息能存在硬盘中的时候，人类如获至宝，如此大的存储量，我们能装下全世界图书馆的馆藏，于是，我们想先放一套盗墓笔记进去。
好嘞，于是，我一个字一个字的将精彩的内容顺序存储在硬盘中，终于，全套的盗墓笔记被存储在硬盘中了，还没来得及高兴，就傻眼了，我不想看秦岭神树，怎么办，这并难不倒我，略加思索，就能想到解决方案，因为是顺序存储的，从开始的地方一直读下去，当恰好跳过秦岭神树章节内容的时候，就做一个标记，记录已经跳过的字节数，下次再看的时候，就直接读到硬盘对应的位置即可，经过一番努力，我找到了并把这个字节数写在了一张纸条上，以便下次可以直接读取，避免一次次的遍历。
后来，我开始有点不耐烦了，因为这张纸条里面的内容越来越多，比如最后一章的位置，终极第一次出现的位置等等，有时我甚至记不住我需要寻找的标记是否在纸条中了，终于有一天，这张纸条丢了，我只能呵呵并且从心底认为，仅仅是顺序存储无法满足我的需求，我需要管理这些内容。
我想，最起码我需要能把全套的盗墓笔记分为8本书吧，只要根据书名，比如邛楼石影，我就立刻能找到对应的内容，我立刻想到了最简单的解决方案，仍然使用顺序存储，只不过在内容录入的时候，给每本书分100MB的存储空间，这样我如果想看第7本，那么直接从600MB偏移开始即可，那么一套盗墓笔记只需要800MB就可以存储，但是，我很快又有了一个更优的方案，在每本书的100MB可用空间内，再进行细分，给每章节进行划分，假设每本书有50章，那么每章节就是2MB空间，这样每章节按照2MB对齐，我要找第6本书的第30章节，就是(500 + 29 * 2)MB 偏移，我甚至都有点洋洋自得了，简单的设计一下就可以再也不用依赖那张小纸条(已遗失)了。
但是，很快我又遇到了新的挑战，因为这块硬盘不是我的，开始说好的800MB没有了，我被要求只能使用8MB来存储全套的盗墓笔记，原先的设计继续使用，每章只能分到20KB，这样有些内容多的章节会越界，而有些内容少的章节又不够饱满，那些没有被利用起来的空间此时显得的是那么的珍贵，于是我开始了小心翼翼字斟句酌的重新设计。
看起来，顺序存储是最节约空间的，那么只有将小纸条(已遗失)的内容也存储在硬盘中了。于是，喝下一罐可乐后，我发觉将章节抽象成一个章节类是一个不错的注意，每个章节是该类的一个对象实例，类成员包括章节名称，章节起始位置，章节字数，每个对象都64字节对齐，这样400章的索引信息只需要25KB即可完成存储，我大大方方的将全部的章节类对象存储在8MB的前32KB区域，后面剩余的全部顺序存储内容，就这样，随着需求的不断增加，我的设计也渐渐开始有文件系统的影子了，尽管我并不知道，但是一切就这样发生了，是那么的自然。
<二>
距我将全套盗墓笔记成功保存在8MB空间里已经过去了19天58分钟32秒，我渐渐发觉更高、更快、更强的绝不限于奥运精神，也充分体现了人类贪婪的本质，无尽的需求催生出这光怪陆离的大千世界。
就在今天下午，我得到一个通知，要么继续使用连续的存储空间，但是只能有4MB，要么去使用不连续的存储空间，总量可以仍然是8MB，那一刻，我的内心反而是平静的，因为我知道，这就是现实，一个不够优秀的系统是无法满足各种刁钻的需求的，并且我并不想丢掉一半的盗墓笔记，所以我必须使用不连续的存储空间，一个不算坏的消息是，就算是不连续，但是每块最小也有2048字节，并且连续的存储空间是2048字节对齐的，还有什么好说的，撸起袖子加油干，这很2017。
当时我的脑海中，浮现出了星空的图像，天顶中每颗闪烁的星代表的就是一段文字，我要怎么将它们串在一起呢？我想，首先要解决的是识别问题，即眼前的这颗星属于哪本书？是的，我需要星的索引信息，每条索引信息对应着一段可存储的空间，记录空间在硬盘中的偏移，长度，内容是属于哪本书，对应内容在书内的偏移，这样通过索引信息就可以在硬盘中找到存储着的盗墓笔记的片段了，于是有了如下的设计，
book_name用来存储书名，hd_ofs存储这段存储空间在硬盘中的偏移，file_ofs存储这段存储空间存储的内容在书中的偏移，chunk_len存储这段存储空间的长度，看起来是能工作的，那么这样的设计够不够好呢，答案显然是需要拿出工匠精神再来打磨一下了。
book_name，这里看起来很糟糕，如果书名很长则无法存储完整，如果书名很短则浪费了存储空间，这里真的需要存储一个书名吗？按照我的需求，盗墓笔记全套是8本书，那么第一本书，我这里记录1即可，依次则是2,3,4,...，我只需要数字就可以进行区分，于是新的设计出现了
但是，新的问题又出现了，我能够通过一个个的index对象找到数据块，但是我该如何找到这些index对象呢？由于每个index对象占用12字节，那么将index搓堆存在一个只存储index的数据块内，那么一个块能存170个index，就像下面这样
很好，现在有了一个index块，那么170个index最多只能映射(170 * 2048)字节(340KB)的内容，可我要存储的盗墓笔记不止这么点内容，所以还需要更多的index块
很好，现在有了更多的index块，我能通过index找到想要看的内容，但是index块也是不连续的，我要如何找到index块在哪里呢？其实，我对之前每个数据块填充170个index对象已经感觉难受了，因为170个index对象只使用了2040字节，这样一个数据块就有8字节的浪费，如果这8字节用来存储另一个index块在硬盘中的偏移位置，那么index块之间就能串联在一起，而我要做的就是找到那个入口
经过了两顿烧烤的谈判，我终于赢得了硬盘第1024个数据块的永久使用权，于是第1024数据块就成为了串起整部盗墓笔记的那个入口