IndexFS: Scaling File System Metadata Performance论文读后感

IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion

这篇论文比较新，发表于2014年11月SC(supercomputing)会议上。SC是高性能计算领域的旗舰会议，每年录取约80篇论文，但参会人数经常超过万人，今年在新奥尔良召开。IndexFS获得了本年度SC的 best paper。该会每年只选出一篇best paper，一篇best student paper。IndexFS的作者 Kai Ren 本身正是CMU的博士生，却得到了best paper，足可见其功力之深。

本文的核心思想就是尝试解决分布式文件系统中metadata (元数据)管理的问题：

• 比如在做N-N Checkpointing的时候产生的高并发metadata操作；
• 一些复杂的管理任务中出现的频繁的元数据读取，扫描；
• 以及文件大小，目录大小不均衡产生的单热点问题

整体系统架构如下：
来自应用程序的metadata操作以及data操作被分配到不同的组件中。Metadata以及一些小于64KB的文件，通过IndexFS服务器来进行管理；真正的数据(大于64KB)通过底层的分布式文件系统来服务。具体到每一个IndexFS中， 并未实现任何replication或者RAID机制，而是通过将metadata或者小文件被组织成大的，顺序文件存储在底层的分布式文件系统中来保证容错。［这个设计非常有趣］

• 首先，类似社交网络，文件的大小，目录的大小都遵守类似的长尾规律：文件系统中大部分的目录中文件数目小于128，但是极少数目录可以有上百万个子目录。为了能够将小的目录存连续的放在本地，并且将大的目录分布到多台机器上，IndexFS引入了Giga+的动态分割算法 (来自同组师兄的工作)，动态的根据目录的增长，引入更多的服务器来存储。

• 其次，针对频繁的读，IndexFS引入了客户端缓存。客户端缓存的最大问题就是不一致性，这在客户端数目远远大于服务器数目的环境下，容易导致缓存无效风暴：一个小的服务器端修改，就能导致海量的客户端重新请求数据。为了避免这个，同时保证缓存数据的一致性。IndexFS为每一个缓存引入了lease，客户端每次申请一个lease，并且缓存相关数据；lease到期之后，会再次向服务器请求延长lease；而此时如果服务器端有写操作，所有的lease延长请求都会被拒绝，而服务器端的修改也必须等到已经办法的lease超时无效才进行。简单的说，这种办法延缓了写操作，保证了数据一致性，避免了无效风暴。

• 最后，针对高频写，IndexFS首先在服务器端使用LSM来存储数据 (实际上使用的是LevelDB)。 LSM是典型的为写优化的存储结构，但随之而来的compaction会占据很长的时间。IndexFS通过只将部分数据(主要是文件的 permission数据，以及一个指针)存储在LSM中，将数据极大的减少了compaction的次数；未缓存的数据也存放在LSM中，但是不再进行 compaction。当需要访问非缓存的数据的时候，可以先搜索缓存部分的LSM，然后直接通过指针找到对应的非缓存数据。代价是一次额外的disk seek，好处是大大减少了compaction，这个performance killer。

• 额外的补充：bulk insertion。这个推荐阅读同时在此次SC PDSW workshop发表的BatchFS，里面更详细的介绍了如何进行bulk insert。同样是来自同组的文章，不得不赞一下。

IndexFS表明了Metadata管理在分布式文件系统中的重要性。我想Object-based Storage其实也是元数据管理能力跟不上的一个不得不进行的选择吧。