追踪CPU跑满

最近测试一个应用遇到问题:一旦压力略涨,应用的CPU就顶满。由于是多线程应用,直接就把系统的CPU耗完了。
本来想用gdb來调试的,结果gdb不给力,就在attach那里卡死,半天不动。后来想到了用perf来调试,果然找到了一处性能热点。修复热点以后,CPU顶满的问题缓解了一些,不太容易出现了,但是,多跑一会儿,还是会有。而且现在出现CPU顶满时,不仅gdb不返回,连perf record -a -g都无法用Ctrl+c来停止了,仔细top命令看了一下,原来系统的sys是100%,usr几乎为0%,也就是说,是卡在内核里了,难怪perf不好使。
perf这样的神器都用不了了,还能怎么办?最后@coly提醒我:用 echo t > /proc/sysrq-trigger 把内核栈整个打出来。好办法,我试了一下,dmesg里一堆信息:

Apr 25 22:37:57 v3 kernel: sheep         R  running task        0 19157      1 0x10000080
Apr 25 22:37:57 v3 kernel: ffff8802b41c5418 0000000000000086 ffff88028761ecc0 ffffea0008b0f478
Apr 25 22:37:57 v3 kernel: ffffffff814ef33e ffff88046ff9b588 ffffea0008b0f478 ffffea0008b0f478
Apr 25 22:37:57 v3 kernel: ffff8803ec6ab0f8 ffff8802b41c5fd8 000000000000f4e8 ffff8803ec6ab100
Apr 25 22:37:57 v3 kernel: Call Trace:
Apr 25 22:37:57 v3 kernel: [] ? _spin_lock+0x1e/0x30
Apr 25 22:37:57 v3 kernel: [] ? __lru_cache_add+0x40/0x90
Apr 25 22:37:57 v3 kernel: [] __cond_resched+0x2a/0x40
Apr 25 22:37:57 v3 kernel: [] _cond_resched+0x30/0x40
Apr 25 22:37:57 v3 kernel: [] migrate_pages+0x9d/0x4b0
Apr 25 22:37:57 v3 kernel: [] ? compaction_alloc+0x0/0x3e0
Apr 25 22:37:57 v3 kernel: [] compact_zone+0x4f4/0x770
Apr 25 22:37:57 v3 kernel: [] compact_zone_order+0xa1/0xe0
Apr 25 22:37:57 v3 kernel: [] try_to_compact_pages+0x11c/0x190
Apr 25 22:37:57 v3 kernel: [] ? native_sched_clock+0x13/0x60
Apr 25 22:37:57 v3 kernel: [] __alloc_pages_nodemask+0x5f5/0x940
Apr 25 22:37:57 v3 kernel: [] alloc_pages_vma+0x9a/0x150
Apr 25 22:37:57 v3 kernel: [] do_huge_pmd_anonymous_page+0x145/0x370
Apr 25 22:37:57 v3 kernel: [] handle_mm_fault+0x25a/0x2b0
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc+0x63/0x140
Apr 25 22:37:57 v3 kernel: [] __get_user_pages+0x12a/0x430
Apr 25 22:37:57 v3 kernel: [] ? rwsem_down_read_failed+0x26/0x30
Apr 25 22:37:57 v3 kernel: [] get_user_pages+0x49/0x50
Apr 25 22:37:57 v3 kernel: [] get_user_pages_fast+0x157/0x1c0
......
Apr 25 22:37:57 v3 kernel: sheep         D ffff88047fc24900     0 19158      1 0x10000080
Apr 25 22:37:57 v3 kernel: ffff880357da9890 0000000000000086 0000000000000000 0000000000000003
Apr 25 22:37:57 v3 kernel: ffff8804700e6ea0 ffff880357da9878 ffffffff812518e2 ffff880357da0000
Apr 25 22:37:57 v3 kernel: ffff8803ec6aa6b8 ffff880357da9fd8 000000000000f4e8 ffff8803ec6aa6b8
Apr 25 22:37:57 v3 kernel: Call Trace:
Apr 25 22:37:57 v3 kernel: [] ? __make_request+0x122/0x5a0
Apr 25 22:37:57 v3 kernel: [] rwsem_down_failed_common+0x95/0x1d0
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc_slab+0x15/0x20
Apr 25 22:37:57 v3 kernel: [] ? mempool_alloc+0x63/0x140
Apr 25 22:37:57 v3 kernel: [] rwsem_down_read_failed+0x26/0x30
Apr 25 22:37:57 v3 kernel: [] call_rwsem_down_read_failed+0x14/0x30
Apr 25 22:37:57 v3 kernel: [] ? down_read+0x24/0x30
Apr 25 22:37:57 v3 kernel: [] get_user_pages_fast+0x124/0x1c0
......

看到了"lock"、“mutex”这些字眼,果然是内核里面卡住了,@coly一看到compact_zone()就明确告诉我,是hugepages的问题,把它关掉试试。用

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
echo no > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag

关掉,应用果然一切正常了。原来以前在hadoop集群上也遇到过类似的问题(所以现在alikernel是默认关掉transparent hugepaes的),不过当时只是CPU略涨,不像现在这个,干脆锁死了。
原来除了gdb,valgrind,perf,还有“echo t > /proc/sysrq-trigger"这样更犀利的办法,@coly告诉我,还有更犀利的,就是连sysrq-trigger都不好使了,可以看
/proc/{pid}/wchan,里面是该进程阻塞位置的内核函数名,在所有办法都没戏的时候可以看它。
学习了。

小记备份遭遇

今天备份机器上的一个目录,用“du -sh .”看这个目录只占用了1.5G空间。但是,我一用tar打包,就半天停不下来,tar包都涨到十几G了还没有打包完。奇怪,哪多出来这么多东西。
查了半天,后来发现目录里有个101G的大文件,而du -sh 对这个大文件的返回结果却是”1.1M“,喔,原来这是个空洞文件,tar却只能老老实实的读数据,所以出来的tar包巨大无比。看来,备份目录前光"du -sh .“是不够的,至少还得类似"find . -size +100M"全部检查一遍大小才行。

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硬盘遇到的问题小,而且目前看开发进度也很好。

Ext4 Workshop 2014

作者:刘峥

2014年3月26日,Napa Valley, CA.  今年LSF/MM Summit 2014会议就在这里举行,因此Ext4 Workshop相应的也就在这里了。会议内容主要是讨论后续一年Ext4文件系统的开发问题。

今年讨论的内容如下:

  1. Data Block Checksums
  2. Reflink
  3. Encryption
  4. Extent Cache Shrinker
  5. Buffer_head Removal
  6. SMR/Flash Device Optimization
  7. Multi-block Allocation
  8. Testing
  9. Mount Options Restrict

与会人员:

  • Ted Ts'o (Google, Ext4/Jbd2 Maintainer)
  • Jan Kara (SUSE, Ext3/Jbd Maintainer)
  • Ric Wheeler (Redhat)
  • Eric Sandeen (Redhat)
  • Lukas Cerner (Redhat)
  • Carlos Maiolino (Redhat)
  • Darrick Wong (Oracle)
  • Zheng Liu (Alibaba)
  • Michael Halcrow (Google)
  • Eric Whitney
  • 两位来自Western Digital的工程师

1. Data Block Checksums

目前Ext4已经具备对元数据进行校验的能力。如果需要对文件系统元数据做校验,仅需通过如下命令即可:

# mkfs.ext4 -O metadata_csum ${DEV}

目前Redhat计划让文件系统支持数据的校验和,来保证数据的正确。由于需要在文件系统中保存每个数据的校验和信息,因此需要在文件系统中创建相应的数据结构来保存信息。目前有两个方案:

  1. 静态方案
  2. 动态方案

静态方案比较简单,类似于metadata checksums,预先在格式化文件系统时直接在每个block group中创建出需要的数据结构。这样的好处是简单,对文件系统的改动比较小,同时很容易根据block group直接找到对应的校验和的位置。缺点则是不太灵活,对一些不需要做校验的block也需要分配出相对应的空间(比如extent tree)。

动态方案则直接在inode或者block group的描述符中直接创建一个B+tree,所有的校验和均保存在其中。这样在查找/创建校验和的时候时间复杂度会有所上升。特别是在block group中分配的方案,由于多个文件可能同时修改同一个block group中的B+tree,所以会有锁争用的开销。

Ted指出静态的方法比较简单直接,可以一点点的改进。如果采用动态方案,则比较复杂。当然,理想情况下,Ted比较喜欢动态的方案。毕竟通过动态方案的实现,不仅仅是data block checksums的问题,连reflink的实现也会简单很多。另外就是一些细节的讨论,比如fsck的时候对data block checksums的检查、df显示磁盘空间时候的计算等等。

2. reflink

由于Mingming Cao没有出席今年的Ext4 Workshop,目前为止reflink的设计方案也没有任何邮件,同时Darrick也不太了解目前reflink的可能实现,因此reflink的讨论就变得极其有限了。reflink(2)调用的目的是创建一个新的inode,但是该inode指向的内容均为另外一个已经存在的文件。这个新创建的文件是COW的,对它的所有修改都不会反应在此前的文件上。正如上面介绍data block checksums时所说,reflink的实现需要创建一个B+tree来记录那些没有修改过的block,而如果有了data block checksums的动态B+tree,则问题迎刃而解,只需要在该B+tree中进行记录就解决了。具体reflink的实现,还是需要等相关的邮件才能揭晓。

3. Encryption

文件数据加密这个之前并不在讨论范围,是开会当天加上的,而且鉴于是Google需要的需求,所以排的位置十分靠前。文件系统的数据加密功能很容易理解,就是将写入文件的内容先进行加密再保存在磁盘上。在Ext4上加这个功能的原因是因为Android操作系统。印象中从Android 2.4之后的版本(我不是Android用户,不太了解 ^ ^)开始,默认的文件系统变成了Ext4。由于用户会在手机上登录各种网站,所以Chromium浏览器会将一些个人用户信息以文件形式保存在手机上。这当然没啥问题,除非您哪天手机丢了。那么这些用户的信息就存在被获取的可能。各位当然也不用担心太担心,因为目前Android系统上会在Ext4上再使用eCryptfs对文件数据进行加密保存。所以您的个人数据还是安全的。但是用Michael Halcrow的原话来讲就是,这完全是个错误。

所以为了纠正这个错误,目前Google的想法是让Ext4原生支持数据加密。关于具体的加解密理论我也不太了解,可说的不多。但是鉴于Google的原因,估计这个特性很快就会加到Ext4上。

4. Extent Cache Shrinker

再提这个问题的原因是在与PostgreSQL开发人员的交流过程中(这次LSF/MM邀请了几位PostgreSQL的开发者来分享一些他们对Linux Kernel开发的希望)发现他们也遇到了Shrinker回收过程过长的问题。这个问题很早就被报告给了社区,不过我一直没有时间去改进,对不起各位了。

目前Extent Cache Shrinker的问题主要是在RB-tree中保存了所有对象的信息。而有些对象由于需要被delayed allocation、seek data/hole功能使用,是不能被回收的,所以在某些情况下,会出现Shrinker扫描很长时间却扫描不到可以回收的对象的情况。对于这一问题,目前有两种改进方案:

  1. 添加一个list专门保存可以回收的对象
  2. 完全放弃LRU-list算法

方案1让Shrinker快速找到可以回收的对象,从而减少等待时间。但是仍然保留了目前的LRU算法,因此还是存在维护LRU的时间开销。另外,由于添加了另外一个list,内存开销会增加近1/3;方案2则完全放弃目前的LRU算法,通过指针记录上次扫描的位置,从该位置继续扫描可回收的对象。这样做可以避免维护LRU算法的开销,减少锁争用。由于目前Shrinker在回收对象时还要考虑inode的PRECACHE标志,因此较为复杂。Ted介绍目前Google内部的做法是完全不回收带有PRECACHE标记的inode,而对其他的则一概回收。当然这样做完全是出于Google自己的需要,PRECACHE的应用都是Google底层的核心应用。因此upstream kernel上不能这样做。同时由于Google大量direct IO的使用,产生delayed allocation对象的机会较少(不能被回收),所以问题也并不严重。

下一步的计划就是同时实现两个方案并比较结果。此外,对于Extent Status Tree,我还在考虑用skip list替代rb-tree的方案以减小锁争用的开销。

5. Buffer_head Removal

目前在Linux Kernel中,buffer_head结构的核心作用尽管已经被bio取代,但是仍然有大量文件系统的代码在使用buffer_head结构来记录文件系统的元数据信息。Ext4就是其中一个。当然,这也是没有办法的事情,毕竟VFS层的很多地方都还需要使用buffer_head结构。Ted提出这个想法的目前是在Ext4中,除了direct IO路径和data=journalled模式外,将所有使用buffer_head的路径中将这一结构干掉。这样做的目的如果是简单重构,其实意义并不大。Ted的想法是通过干掉bufferred IO路径上的buffer_head,从而避免使用buffer_head中的Delayed标记。这样就可以避免在blocksize与pagesize不同时处理的麻烦。随之而来的计划便是将dioread_nolock特性默认打开,从而提高高速设备上direct IO的性能(此特性可以解决目前Ext4中direct IO路径上的扩展性问题)。

尽管前景美好,但是Ted和Jan表示没时间搞。所以哪位有兴趣的可以试试看,做完这个,对整个Ext4的读写流程会非常熟悉的。

6. SMR/Flash Device Optimization

这块主要的改进思路其实已经体现在Ted发的RFC中了(http://lwn.net/Articles/579564/)。主要是两方面的改进,一方面是针对日志的改进,尽量减少对日志的频繁刷新,从而避免由于SMR随机写性能影响文件系统,造成性能下降。另一方面是对mballoc算法的改进,做到对SMR友好。鉴于目前大家基本都没有拿到可以测试的SMR硬盘,所以大家并没有什么意见提出。

7. Multi-block Allocation

对于mballoc算法的改进源于Lukas对使用thin-provision的Ext4文件系统进行测试时发现的问题。问题是mballoc目前的算法总是倾向于在整个块设备上分配磁盘空间,即便块设备的开头有空闲空间,mballoc也经常会分配块设备后面的空间来进行使用。这在传统磁盘上当然没有问题(其实还是有问题的,因为越往后磁盘性能越差),但是对于thinp设备就要命了,因为thinp设备根本就没有宣称的那么大的空间,所以文件系统总是分配后面的磁盘空间thinp设备自然受不了。Lukas目前有补丁来解决这个问题。但是从长远来看,还是需要改进mballoc的分配算法。目前最大的问题是很多mballoc中的代码除了Andreas Digler(mballoc的作者)就没人知道为啥要这么写了。。。

另外谈到的一个关键问题是如何测试来确保分配算法确实有改进和不是造成性能的下降。大家还是给了些意见的,包括用一些成熟的测试工具,用已有的磁盘使用情况的Tracer等等,总之目前对于mballoc的改进还没有具体方案,只是有这个想法。

8. Testing

Ted介绍了自己的测试方法,再次强调了测试的重要性并希望大家多测试。同时感谢了Eric Whitney的测试工作。Ted也提出了对于xfstests测试框架的改进意见,希望Redhat的同学能进行改进。

9. Mount Options Restrict

这个话题去年就聊过了,但是还是没有彻底解决。主要问题是去年Redhat主要在弄RHEL7,没空搭理这个小问题。但是今年RHEL7大问题都解决了,所以这个小问题又提上桌面了。主要问题还是发行版希望使用Ext4内核模块来挂在Ext2、Ext3文件系统。但是这样就存在到底这么多特性哪些特性可以用在哪些文件系统上。今年这件事情从Lukas转到Carlos身上了。

今年预计Ext4会开发的新特性如下:

  • Data Block Checksums
  • reflink
  • Project Quota
  • mballoc优化
  • Ecryption
  • Extent Cache Shrink优化

debuginfo的rpm包

之前rpmbuild -ba xxx.spec能自动打出binary包和对应的debuginfo包,但是我不想分成两个包,希望binary包里就是带调试符号的,在网上找了一堆,最简单的办法就是在spec文件里(头部)加一句

%global debug_package %{nil}

那些说在~/.rpmmacros里加东西的办法似乎都不好使。

但是,几天后,我在另一台机器上又遇到了相反的问题:rpmbuild -ba xxx.spec默认就不打debuginfo包。估计是机器的环境问题,不过谁知道又是哪个文件闹的环境问题呢?于是又检查了一圈,哦,原来是没有装redhat-rpm-config包,所以没有bsp-compress这个工具,故而打不出debuginfo包来。
机器上的软件环境,是个头疼的事,看来,docker也许真有搞头。

1 2 3 4 14