忆一篇顶会的发表历程

最近关于顶会的讨论一波接着一波，作为一个运气较好的人，有幸在17年的SC上发表了分布式文件系统LocoFS的论文。其发表历程亦是坎坷。

我硕士期间主要研究KVM虚拟机和OpenStack平台，在2012年到2015年间，正是云计算发展的黄金时期。OpenStack的复杂性让我一直纠结于自己工作的正确性，记得当时整天在实验室里闭门造车，突然某天看到北京有机构培训OpenStack，不顾导师劝阻跑去培训的一周，结果发现培训老师还没有我了解的多，回来之后有了很大的信心。在OpenStack的研究过程中，我分别接触了GlusterFS和CephFS文件系统，并基于分布式文件系统的特点构建了软件自由组装的云镜像共享系统，极大的提高了虚拟机的启动速度和软件部署速度。同时为了满足硕士毕业需要，魔改了QEMU的qcow2驱动，使其能够支持深度的软件解耦合。磨磨蹭蹭算是把硕士弄毕业了。但部署过程中GlusterFS和Ceph结构上的精彩设计让我记忆尤深，特别是相比于Google File System，这两个系统更代表了分布式文件系统发展的两个方向。并且我总认为GlusterFS的某些缺点可以被改进。这也让我博士期间一开始就投入了对于这两个文件系统的研究。

LocoFS最先的想法是由于在Ceph上做了一个类似于现在BlueStore这种直接访问闪存的驱动后产生的，由于这个驱动做了之后性能不好，我想放弃但又没有新的研究方向。就想看看是否可以在改进GlusterFS上做一些工作。后来偶然看到了IndexFS这篇论文，让我有了在GlusterFS上改进元数据访问的想法。我当时的目标就是构建一个分布式无锁访问的分布式元数据服务器。

一开始我打算修改GlusterFS，后来发现很困难，之后参考了IndexFS的源代码，决定从头写一个分布式文件系统的元数据管理服务。通过使用KyotoCabinet和Thrift两个中间件，我写出了第一版的LocoFS，并且与GlusterFS和Ceph在元数据上做了对比。如今还记忆犹新的是Ceph的元数据访问性能实在太差，以至于我认为我的Ceph配置不正确，让我在大部分时间不是调优LocoFS，而是调优Ceph。当然这也为我后期在Ceph上的工作打下了不少基础。通过近两个月的调优和测试，我写出了了第一版的LocoFS论文，投了16年的SC。但是并没有被录用。主要认为我的实验不够充分，LocoFS的重命名机制成为了一个巨大的问题。

在这之后我比较沮丧，但在导师的鼓励下，我大改了LocoFS，重新设计了重命名机制，并利用B+树来加速访问，同时几乎重写了代码，并且让LocoFS支持了数据的访问。这次将论文投稿在FAST17上。但依然没中，到此为止，我这个工作已经做了一年了，我再次陷入了沮丧，已经有了放弃这个工作的打算。

之后导师再次给予了我积极的鼓励，在这样的情况下，我加入了一直不想对比的Lustre文件系统，由于Lustre部署起来特别复杂，我对这个文件系统也不是很了解。所以在接下来的日子变为部署和理解Lustre文件系统，通过近两个月的调试和实验，我重新梳理了论文的结构，并且在系统的很多地方做了妥协。最终发在17年的SC上，被录用了。

在整个论文的发表过程中，我无数次在夜深人静，没有人的时候开启shell，测试数据，为的是保证数据的可靠性。同时，为了避免对比其他文件系统时没有将其性能发挥出来，我学习了GlusterFS，Ceph和Lustre的性能调优。为了加速实验，我用ansible写了一堆分布式文件系统的自动化部署工具。在论文的写作过程中，我和我的师兄无数次搞到很晚，甚至没有休息。记得最后一次投SC的时候，我连续52个小时没有合眼。我的车开出清华的时候交了200多元的停车费，我爱人怕我继续开车出事，叫了代驾把我的车开回了住的地方。在论文最后投稿时，佛罗里达大学的胡杨博士帮我连夜修改了各种英语表达错误，让论文在英语表达上有了很大的提升。

现在想想，LocoFS之所以能够成功，很大程度上是在各个细节上做了各种各样的妥协，使之在实用的基础上具备较好的性能，经得起推敲，具有很好的兼容性。其次，导师坚定的对我工作的认可让我在反复被拒后依然整装备战。如今虽然随着自己博士毕业与学术圈渐行渐远，但是发表一篇顶会对于一个博士生是一个巨大的考验，自己也在这样的磨砺中不断成长。