2012年3月30日，我和刘峥一起去Mountain View参加了ext4 workshop，和google的ext4开发人员以及ext4 Maintainer Ted T’so一起进行了交流，会议进行的非常顺利，我们一起就淘宝感兴趣的ext4新特性以及ext4下一步的开发计划进行了讨论。
首先Ted T’so介绍了ext4以及bigalloc在google的应用，目前google所有的机器都已经运行在ext4上了，并且no-journal也已经占大多数。关于bigalloc,目前google主要使用模式是fallocate+direct sequential write。我们提到了在某些集群遇到使用fallocate后写放大的问题（一次写入由于元数据的修改可能会导致多次的写io)，并提到了我们可能的解决方案（一种很hack的方法，让应用来保证总是先写入后读取），然而出乎我们意料的是google内部竟然也是这么干的，于是我们双方决定提出一个新的fallocate参数（FALLOC_FL_NO_HIDE_STALE），让这种hack的方案光明正大起来（不过可惜在后来的Linux Storage and file system summit上其他的文件系统开发人员对这个并不认可，所以可能最终我们只能在ext4内部来实现了）。
第二个议题是关于fsync的，当前extN系列的文件系统的fsync虽然用户可以选择相应的fd来做，但是到文件系统内部还是通过commit整个文件系统的journal来实现的，再加上data=ordered模式下需要写入对应的文件数据，导致fsync的代价很大，overhead也很多。因此我们就能否优化fsync使它仅作用于某一个文件，从而加速fsync进行了讨论。可惜的是，由于jbd/2本身机制的问题，这个的实现可能需要修改或者替换整个jbd2，所以暂时被搁置了。
第三个议题是关于extent tree cache的。xfs的开发人员Dave Chinner曾经指出由于extN文件系统是基于bitmap模式的，这样导致数据分配比较慢，另外每个extent的大小是有限制的（目前是128MB），文件太大以后extent数目会增多，用户如果随机读取文件会由于元数据的读入而变慢，董昊曾经提出修改extent的格式来突破extent大小的限制，可惜的是由于存在多余页面的写入问题，Ted T’so并不是很喜欢这个方案。google目前的做法是在内存中保存一个big extent tree，这样多个在硬盘中的extents可以在内存中被合并为一个big extent，这样读数据时必需的元数据读取就不需要走复杂的get_block逻辑，从而起到加速的效果（一个可行的实现是在打开文件的时候读入整个元数据并创建一棵big extent tree,从而使后续的文件元数据读取可以直接访问tree，避免多余的i/o操作）。我们对这个特性也很感兴趣，Ted表示可以让google的开发人员把代码整理一下，发到社区，我们后期可以在超大文件中使用。
第四个议题是extent io tree，这个实际上是第三个议题的衍生。big extent虽然解决了多余的元数据读取，但是对于delayed allocation,punch hole以及多线程同时读写操作仍然无能为力。我们需要一种in memory的io extent cache tree，它主要可以有一下几个作用：
1）更好的支持delayed allocation环境下的fiemap和punch hole。由于delayed allocation的一些特点，导致fiemap和punch hole都必须通过遍历page所含有的buffer_head来确认，非常低效，通过in memory cache可以解决这个问题。
2）更好的支持数据库等direct io型业务，数据库业务会同时发起多个dio read/write，目前direct read可以通过dioread_nolock来完成并发，但是对于direct write还需要串行。如果可以实现range lock，那么多个针对不同区域的direct write就可以同时进行。range lock可以作为in memory extent cache tree的一个附加产物被很容易的实现，从而最终提升数据库的并行读写能力。
3）优化现有的代码，使extent操作更加高效。
目前社区有几套方案，但是都有各自的优缺点和局限性，需要统一，我们也表达了淘宝对这个特性的关注。
第五个议题是关于文件系统分配策略的。我们在文件系统的调优中遇到一个问题，对不同特点的文件使用不同的分配策略，比如索引文件尽量往磁盘的开始处分配（那里的数据读写速度相对较快），数据文件可以往磁盘尾部分配。通过大家的讨论，一个可行的方案是添加O_HOT, O_COLD标志（比如上面的例子中索引文件使用O_HOT，数据文件使用O_COLD），这样文件创建和打开的时候可以显式的通知文件系统，从而在未来的磁盘分配中采取不同的策略。
第六个议题是关于data=journal模式的，redhat的开发人员提到data=journal模式有一些问题，并在实际的用户中很少使用，但是却增加了开发和测试人员的负担，Ted对此表示同意，目前大家的看法是以后可能会逐渐去除data=journal这种模式，所以我们以后也不会推荐这种模式了。
第七个议题是关于inline data。Ted对inline data的开发工作进行了询问，并表示下一步将开始review，并争取早日合并。
第八个议题是关于resize。目前ext4 resize在64 bits支持，bigalloc支持，flex_bg支持方面都还有很大缺陷，下一步需要进一步改进。
第九个议题是关于ext4 patch的review问题。目前Ted一个人在做review，导致速度会比较慢，以后可能会要求所有的开发人员都需要review他人的patch（这个是向xfs学习），另外在任何新特性开发的过程中需要使用xfstests做回归测试，从而保证开发质量。
最后，Ted对淘宝对ext4社区的贡献表示感谢，并邀请我们参加每周的例行会议，以便大家更好的沟通。
相关文章
转载请注明：爱开源 » ext4 workshop总结