LSF/MM Summit 2014

作者:刘峥

今年LSF/MM会议的内容lwn.net上已经有文章进行详细的介绍了。鉴于我本人分身乏术造成mm track基本没有听,同时会上讨论的有些问题本人理解也十分有限,所以推荐大家还是去lwn.net上看一下上面的文章。这里仅仅是总结我认为比较重要和关注的问题,希望通过这篇文章能让大家了解目前Linux Kernel在文件系统、存储和内存管理方面需要解决的问题。

这次的LSF/MM会议的议题基本可以分为三个大的部分:

  1. Linux Kernel目前存在的问题
  2. 来自业界和社区的分享
  3. 新技术带来的新问题

尽管1中的议题占了会议的大部分时间,但是个人感觉这次LSF/MM最重要的是2、3两部分。而且会对未来一段时间的内核开发带来较大的影响。

1. Linux Kernel目前存在的问题

这一部分包含了如下内容:

  1. Page Cache的相关问题
  2. 测试
  3. blk-mq的相关问题
  4. direct I/O

1) Page Cache的相关问题

这次LSF/MM上关于page cache的讨论有两个,一个是关于32位机器上大空间块设备寻址的历史遗留问题;另一个是支持大于4k内存页的page cache。

32位机器上对于大空间块设备寻址是一个历史遗留问题。这个问题说来很简单,32位机器的内存寻址范围是2^32=4GB,目前Linux Kernel常规内存页大小为4k,因此对于系统page cache来讲,最大可以支持的磁盘设备的容量为4GB x 4KB = 16TB。由于目前嵌入式设备和ARM服务器的广泛使用,出现了32位系统对于超过16TB大容量块设备使用的需求。对于这个问题大家的意见还是就不要解决了,如果用户真的想用,内核会给出信息提示用户这种使用方法的风险。

目前Linux Kernel其实已经有针对Anonymous Page的大页支持了。但是对于page cache,目前Linux Kernel仍然仅支持4k大小。调大page cache的好处是减少内存页管理的开销。目前看,page cache大页支持的关键仍然是防止内存的碎片化,让page cache支持大页并没有想象中那么困难。page的迁移和压缩功能在此前实现Anonymous Page大页时已经基本实现了。目前的问题主要是如何解决那些不能移动的内存页。尽管大家也提出了一些建议,但是似乎问题仍然比解决方法多。

此外,Dave Chinner还提到了让文件系统支持大于page size的block size。目前Linux下主流的Ext4、XFS、Btrfs文件系统的block size大小均为4k。Dave的想法是能否借助目前增大page cache的机会来突破这一限制。同时,这样带来的一个副作用就是buffer_head彻底退出历史舞台。在2.6内核中buffer_head作为IO请求的核心作用已经被bio所取代。但是,目前仍然有大量文件系统的代码,特别是文件系统的元数据信息需要使用buffer_head。buffer_head的使用给文件系统开发者带来了很多不必要的麻烦。问题其实都是老生常谈了,但是真想解决确实难度不小,由于buffer_head的使用涉及诸多文件系统,对它的任何修改都不容易。

最终的结论还是那句很简单的“show me the code”。各位可以关注fsdevel@ 和mm@ 邮件列表,最近会有补丁。

2) 测试

继去年xfstests讨论之后,今年Dave Chinner和Dave Jones继续讨论测试的话题。讨论从xfstests开始,说是讨论不如说是抱怨,很多人在抱怨xfstests目前存在的问题。这些大家直接去看lwn.net上的文章就好了。本人表示比较关心的是Dave Chinner对于目前Redhat内部xfstests对于XFS和Ext4的测试覆盖率的说明。目前Redhat内部对于XFS的测试覆盖率约为75%,而Ext4的测试覆盖率仅为65%。本人表示怪不得有那么多Ext4的bug需要我来修呢。。。其实在后面Ext4 Workshop上依然有关于测试相关的话题,Redhat当时简单说明了他们对于文件系统的测试情况。应该说测试的还是很全面的,所以大家放心。

而James Bottomley提出目前其实社区缺少性能回归测试。本人觉得这是切中要害,目前无论是文件系统还是内存管理的开发者,提交补丁前大部分仅做了功能性测试和压力测试,没有一个很好地性能回归测试对修改前后的性能进行比较。而这也造成了Linux Kernel不同版本之间存在较大性能差异的原因。

3) blk-mq的相关问题

blk-mq本身已经合并到upstream内核中了。这次讨论的是前不久Christoph Hellwig关于scsi-mq的补丁。目前计划是在3.16版本的时候开始合并scsi-mq的相关补丁。现在的问题是还存在一些性能退化的问题和驱动的支持问题。

4) direct I/O

direct I/O绝对是一个老生常谈的问题,Kent Overstreet今年继续讨论如何改进direct I/O。其实大家目前对于direct I/O改进的目标是明确的,即重构代码,不使用buffer_head结构,而是直接使用bio来提交IO请求,从而简化代码路径。今年讨论的是如何实现这一目标。Kent的想法是借鉴目前buffered I/O路径的实现,通过回调函数的方法让文件系统对应磁盘块的分配信息,然后由VFS负责刷新page cache。个人觉得direct I/O去掉buffer_head中最复杂的部分是get_block()这个回调函数。因为有buffer_head的存在,目前文件系统的元数据在从磁盘上读取之后是可以保存在内存中的,而换用bio之后,这些元数据信息要么每次从磁盘读取,要么需要单独的结构来进行保存。而目前文件系统的get_block()函数是同步的,这个性能开销是用户完全不能接受的。所以明显需要一个数据结构来保存曾经访问过的文件系统元数据。

2. 来自业界和社区的分享

这一部分包含了如下内容:

  1. 来自PostgreSQL社区的声音
  2. Facebook目前遇到的问题与挑战

1) 来自PostgreSQL社区的声音

这次请PostgreSQL的开发者来LSF/MM的目的就是听取应用开发对于目前内核开发的一些建议。事情的起因是PostgreSQL最近在新内核上出现的性能退化以及长久以来磁盘IO方面存在的问题。首先要说明的是PostgreSQL目前所有的IO操作都是buffered IO(我一直以为是高大上的direct IO)。这样就出现了PostgreSQL中目前解决的不是很好地问题。PostgreSQL目前使用的WAL会确保数据库事物的正确性。正常情况下,磁盘的带宽可以保证WAL写入的低延迟。但是当PostgreSQL开始回写脏数据的时候,由于大量的脏数据从PostgreSQL中拷贝到系统page cache中并sync写到磁盘,造成磁盘带宽短时间内被占满,从而影响PostgreSQL数据库整体的延迟。当然,大家提出的解决方法也有很多:ionice、cgroup等等,但是最终讨论没有结果。Ted希望PostgreSQL开发者能够出一个简单程序来复现问题,以便内核开发者复现问题。

第二个被讨论的问题是关于double buffering的问题。根源依然是buffered IO。由于PostgreSQL使用buffered IO,造成系统中内存的浪费,因此PostgreSQL开发者希望内核能够提供一个接口指明某个区域的page cache不再需要,从而可以减少内存开销。有人说明可以通过fadvise(2)+DONTNEED来完成。但是PostgreSQL的开发说这样会造成这些内存页被再次读回内存(按理说不应该啊)。

最后PostgreSQL讨论的内容是最近新内核上遇到的性能退化问题。主要是透明大页、NUMA等。但是大家讨论并没有什么结论性的东西。

2) Facebook目前遇到的问题与挑战

Chris首先介绍了一下目前Facebook内核部署情况。其中绝大多数是2.6.38内核;少量是3.2 stable + 250 patches;极少量3.8 stable + 60 patches。在backport的补丁中绝大多数是网络和内核调试相关的补丁。

对于目前Facebook遇到的问题主要在如下几个方面:

  1. 数据库(buffered IO延迟、spinlock抢占、细粒度IO优先级)
  2. Web日志(buffered IO限速)
  3. 内存回收和压缩(高阶内存分配的延迟过大、内存回收策略)
  4. 监控(某些时候仅仅靠dmesg不管用)

Chris指出在Facebook内部最常见的两个问题是Stable page和CFQ。提到这两个本人真是感同身受啊,所以目前阿里内核已经将stable page的补丁revert掉了(Google也这么干了^ ^)。

其实Facebook家尽管也是互联网公司,但是与Google各种高大上的分布式系统不同,构筑起Facebook的基石依然是MySQL数据库,所以数据库的性能对Facebook来讲是十分重要的。数据库这里提到的三个问题在阿里也是存在的,我们的数据库也会碰到buffered IO延迟高甚至某些情况下会将内核hang住的情况。spinlock的抢占对于本人更是印象深刻,去年双十一前压力测试就遇到过类似的问题。

对于buffered IO的延迟问题。其实与PostgreSQL遇到的问题类似,依然是回写数据过多造成磁盘带宽的短时间占满。这块的意见是让writeback线程具备ionice的功能,或者至少可以指定IO优先级,避免回写过多。同时Chris提到Josef已经修改了btrfs来限制buffered IO的速度(看来Facebook已经开始全线换用btrfs了)。

高阶内存分配延迟大、内存回收策略造成某些应用性能差这都是Linux Kernel多年来的老问题了。对于一个通用操作系统来讲,内存回收策略的修改很容易使某些应用性能提升的同时造成某些应用程序的性能退化。

可以说,互联网公司遇到的真的是有很多共通的问题。比如buffered IO延迟和回写带宽控制、内存回收策略、内存回收延迟等等。

3. 新技术带来的新问题

这一部分包含了如下内容:

  1. SMR硬盘的相关讨论
  2. Persistent Memory的相关讨论

1) SMR硬盘的相关讨论

SMR硬盘是未来传统机械硬盘发展的新方向。目前SMR硬盘的产品市面上已经可见。这种硬盘由于内部物理结构的改变,相比传统磁盘,SMR硬盘的随机写性能更差(传统硬盘已经很渣了)。所以为了规避SMR硬盘在随机写操作性能上的问题,目前由WD主推了一种新的SCSI协议ZBC。即通过主机和应用程序来主动控制数据写入的位置,从而避免因随机写引起的性能开销。关于SMR硬盘的具体介绍,请看此处(https://www.cs.cmu.edu/~garth/papers/05_feldman_022-030_final.pdf)。

LSF/MM上有两个议题是关于SMR硬盘的。其中一个是讨论目前的ZBC协议。这个其实没有什么特别需要说明的,只是协议各种细节的讨论...。另外一个议题则值得详细说明。即Ted Ts'o和Dave Chinner主持的关于SMR硬盘在文件系统上优化的议题。Dave Chinner给了一个突破常规的想法。既然目前所有文件系统都需要针对SMR硬盘进行优化,那么是否可以考虑将目前的文件系统进行分层。即分为namespace layer和block allocation layer。在namespace layer中,每个文件系统有自己的磁盘格式。然后通过统一的接口向block allocation layer请求分配磁盘空间。而block allocation layer则可以实现为不同的dm设备。针对不同的设备,实现不同的磁盘块分配算法,实现对不同设备的优化。比如dm-smr、dm-disk、dm-flash、dm-thinp等等。此想法确实新颖,但是问题也不少,首先就是开销问题。特别是对于互联网应用。所有应用程序都希望文件系统尽可能的薄,不要引入不必要的开销。而Dave的想法平白引入了一层,开销必然要增大。其次实现起来也过于复杂,需要为不同设备实现一个算法。最后,此前每个文件系统已经有自己的磁盘块分配算法了,而且可以针对每个文件系统的特点进行有针对性的优化。分开之后是否还能够有非常好的优化效果,目前还难以评估。因此Ted其实对这个想法的可行性持怀疑态度。Dave Chinner的想法可能预示着未来一段时间文件系统开发的一个新的方向。

2) Persistent Memory的相关讨论

对于Persistent Memory的支持本身社区已经有补丁了,并且最近就会被接收。这次主要讨论目前对于Persistent Memory支持中存在的一些问题。Intel的Matthew Wilcox提到了下面的一些问题。首先是msync。目前如果应用程序调用msync,尽管内存地址和长度都会作为参数传递进Linux Kernel。但是内核目前是根本没有处理的,sync的时候直接调用vfs_sync()把整个文件一刷完事。这个修改本身当然并不复杂,但是由于修改了已有API的行为,所以用户程序能否接受才是核心问题。第二个问题是关于mmap(2)的MAP_FIXED。这个标记会要求mmap在指定位置进行映射,但是副作用是映射区域已有的映射会被释放掉。于是Matthew想定义一个新的标记MAP_WEAK来避免这个副作用。当然还有其他一些问题。总之比SMR硬盘遇到的问题小,而且目前看开发进度也很好。

CLSF 2013讨论会纪要(一)

10月17日到18日两天在LSI上海办公室参加了 CLSF2013 讨论会。简要记录之,如有错误,欢迎拍砖。

第一天早上开场先是由LSI亚太区的总裁致辞欢迎大家,因为请来的几乎都是LSI的客户:华为、oracle、阿里、百度、腾讯等(其实还有竞争对手,比如fusionio:)。当然,LSI做为东道主不仅提供了场地还提供了中午饭,还真要谢谢人家。

先由Jeff Liu介绍去年xfs的进展。xfs去年最大的改动是加入了自描述的元数据,其实就是元数据的CRC校验,如果读取时发现校验对不上,就直接返回IO error。因为这个校验的增加,还将superblock升级到了v5,从测试来看加此校验只增加了不到5%的CPU消耗。
涛哥发问:“你是在机械硬盘上测的吧?机械硬盘太慢,所以校验计算增加的overhead比例就不明显,你应该用SSD进行测试。”
Jeff回答:“我们oracle没钱,我就一个笔记本,只能自己买了一个ORZ,不,是OCZ的便宜SSD做测试,overhead也就是这个水平。“
xfs_io现在开始支持SEEK_DATA/SEEK_HOLE,可以直接找到文件空洞所在的偏移。通过在mount的时候计算transaction log的保留空间(而不是像过去在运行时计算),减少了运行时的压力。在xfs做日志恢复时加入了readahead,减少了读延迟,加快了日志恢复的速度。
还有一些特性尚未merge code,但是正在开发中的,比如:在线文件系统缩容(涛哥一个劲的追问:谁会有这么奇怪的需求?);为空闲inode单独建一个btree,以加快小文件创建(也就是分配inode的速度);对inode cache的压缩(这里要解释一下,xfs是一款有20年历史的老文件系统,当初从SGI弄到linux里来的时候linux的vfs还不完善,所以里面有很多代码是做了今天vfs的很多工作的,所以inode也比较肥大:超过1700字节,有了压缩以后,可以减小到308字节),不仅省内存,也减少了磁盘IO。
接下来的讨论是关于online fsck的,
涛哥:我们线上有需求,如果机器异常重启,做fsck太慢来不及,所以希望先启动机器,然后慢慢的做online fsck,但是ext4是没有online fsck功能的,xfs有吗?
Jeff:xfs的目标,是不需要fsck,元数据自我描述自我恢复,现在AG(xfs的块分配单位,allocation group)就是自我管理的
Coly:我们当初挑选过的,xfs的代码量要几倍于ext4的,以我们这么小的团队和互联网对文件系统那么小的需求,ext4更加合适
Jeff:这个,xfs代码量大的问题,我得说两句,首先,xfs代码风格比较古老,函数调用里每个参数都是单起一行的,而且,注释量达到30~40%,比ext4的10~20%高得多,所以代码量自然也大得多。
涛哥:如果xfs有类似online fsck的功能,就是文件系统一边被使用一边做修复检查,那我们会考虑部分使用xfs的
Jeff:现在没有这个功能,也没有开发计划
涛哥:那xfs还有什么优势?
Jeff:xfs的需求是来源于付费的大客户的,要求大文件的支持、良好的稳定性、良好的扩展性、高并发IO下的良好性能
文卿:ext4在打了directio nolock的补丁以后,并发读写已经赶上xfs了....
总之,Jeff被涛哥一顿烂虐。后来吃晚饭的时候,涛哥反复申明:”我不是要难为Jeff,是我确实遇到一些需求ext4目前不好解决,如果xfs能满足我们就考虑部分使用xfs“,我:”你这样问法是不对的,你拿着火枪跑到武术馆说‘你们的武术能快过火枪吗?能快过我就学你们的武术’,这不是踢馆是什么?”

Intel的Yuanhan Liu(不是我故意输入英文名,是coly给的日程表里都是英文名,没办法)介绍和吴峰光一起做的0-day kernel test自动化框架,能自动检测kernel tree的性能变化(不管是好的变化还是坏的变化),然后自动bisect找到引起变化的patch,给相关人员发信。其实我们这边(阿里)非常需要这样的自动测试系统,因为内核组一个专职QA都没有。于是我们怂恿intel的同学把这个自动化测试的东东做成一个测试云服务,我们好接入,“做为回报,我们会持续的大量的继续购买intel的CPU“(Coly原话)。


clsf-2013

吃中午饭的时候我向Jeb Tang讨教了线上遇到的磁盘IO hang住的问题,Jeb表示,这个问题极难查找原因,因为磁盘的firmware、raid/sas卡的firmware、内核驱动都有嫌疑,而且他感觉,6Gb SATA口很多人反映稳定性不如3Gb的,更不如SAS口,所以google在服务器定制的时候,干脆在每个sata口上加了个reset芯片,一旦发生io hang住的情况,自己调那个芯片硬件reset那个sata口(相当于插拔硬盘,只不过不需要人肉了),就返回io error了。我于是专门问了这个reset芯片的价格:一个0.6美元。
边吃饭还边请教了百度的谢广军同学对于已经mount了的磁盘,插拔后怎么做到盘符绑定,原来用udev可以。回头我试试。

下午是我厂的文卿同学介绍ext4的进展。extent status tree终于进入upstream,以前aio会等在ext4元数据分配这个地方,现在有了extent status tree,等待少了很多。以前ext4的"打洞“只支持extent的文件,现在也支持间接块式的文件,甚至还支持bigalloc下的打洞。另外,bigalloc和delay allocation合用会有warning的那个问题也解决了,当然,Ted否决了我的patch以后,用了一个也不咋高级的方案。算了,不提这些了。谢广军同学对bigalloc表示了兴趣,当然,目前还在观望,主要看其他屌丝(比如我们)有没有把bigalloc的坑踩完。文卿同学说到了online fsck的那个需求,
文卿:目前能支持online fsck的文件系统就是三个,linux上的btrfs,freebsd上的zfs和ffs,btrfs太不稳定,zfs和ffs并发IO的性能不如ext4,用户不接受。所以目前我们还在想办法。另外,我们现在也在做ext4的quota功能,但是subtree的dir quota不准确,也需要改进。rhel7以后就默认xfs了,在这之前,ext4还是得发挥余热....
广军:不是吧,我们百度才不到20%的用的是ext4,还要推广呢,你这就”发挥余热“了?!
我:看来终于有一个新东西我们比百度的同学推得快了

来自oracle的Bob Liu同学介绍了zswap。zswap其实就是把要swap到硬盘的page先压缩再存磁盘,这样可以减少IO延迟,但是会多耗一点CPU。这个功能最早是在IBM的power架构上做的,用的是power带的协处理器来做LZO压缩,所以比较合适。

来自苏州柯达的majianpeng同学介绍了他所在公司的监控系统对文件系统和存储的需求。他们一开始用的是IPSAN做后端存储,但是发现成本太高,于是改用自己开发的用户态的文件系统来合并小文件为大文件(类似淘宝的TFS),现在已经成本很低了,也满足了需求。我很好奇的问jianpeng同学何以在软raid社区发了那么多patch,他说那不是他的工作是他的兴趣爱好属“不务正业”,我很感慨,我应该向他好好学习。


clsf-2013