最新消息:

ext4 workshop总结

未分类 admin 1714浏览 0评论

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总结

发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址