系统装在软raid上

前一阵遇到一个系统装到软raid上后设备名对不上的问题。正常用kickstart安装rhel或centos时,可以创建软raid设备,例如/dev/md1,然后把系统装到md1里,装好重启后可以看到根目录就在/dev/md1设备上。但是,同事用无盘环境装的,重启后设备名字变成了md127,系统是自动把软raid设备找到了,但是给它的名字不是安装时的名字。试着在/etc/mdadm.conf里把/dev/md1加上,重启还是无效。
后来才想明白,mdadm.conf配置文件自己就放在软raid上,在识别软raid以前,上哪儿去找这个文件啊。不是修改系统的,而是修改dracut里的mdadm.conf,这个修改也不麻烦,改好/etc/mdadm.conf后重新mkinitrd一下,新的mdadm.conf就带到新initrd里去了。这次重启,设备名正确了,是/dev/md1。

那md127是咋来的?
再翻了代码,原来,dracut里的sbin/mdadm_auto脚本里有一句:

/sbin/mdadm -As --auto=yes --run 2>&1 | vinfo

如果找不到etc/mdadm.conf,就会用mdadm工具来自动寻找并组装旧有的软raid设备,“-A”表示Assemble,看看mdadm的源码:

(Assemble.c)
create_mddev()
    ----> find_free_devnm()

char *find_free_devnm(int use_partitions)                         
{                       
        static char devnm[32]; 
        int devnum;                                                
        for (devnum = 127; devnum != 128;                
             devnum = devnum ? devnum-1 : (1<<20)-1) {
             ......

就是从127往下递减来作为设备名称的。

感谢君瑞同学提的问题,我也学到了很多。

ext4突然拔盘

测试ali-kernel中发现,如果进程正在对一个ext4文件系统做普通的写入:

dd if=/dev/zero of=/test/ok bs=1M count=1048576

突然拔掉盘,由于io-error-guard的作用,能迅速把ext4变为read-only,dd进程直接返回Input/Output error然后退出,但是如果接着umount,那么umount命令就一直hang住了。
跟了一下发现是文件系统发现io错误开始清除inode,ext4_destroy_inode() --> ext4_ioend_wait()判断i_ioend_count总是不为0,所以一直等待。没啥新鲜的,加trace跟踪i_ioend_count,原来ext4_free_io_end是负责将此计数减一的,但是调用ext4_free_io_end的有很多函数,看上去ext4_end_io_buffer_write()应该是调用者(名字叫buffer_write嘛,普通的写入就是这个),查了半天,这个函数根本不调用ext4_free_io_end(),那谁在调,又查,才发现是ext4_end_Io_buffer_write()在结尾时调用

queue_work(wq, &io_end->work);

让工作队列来负责下面的事(这个work_queue,最容易看漏了),实际的工作交给ext4_end_aio_dio_work()来做了,你看这函数名字,又是aio又是dio的,我的写入既不用aio也不用dio,却非得走到它这里来,太误导了,还是upstream的名字改得对,就叫ext4_end_io_work()得了。然后就一眼看出ext4_end_aio_dio_work()里有蹊跷了,里面有个逻辑,如果io出现错误无法进行,居然不调用ext4_free_io_end而直接返回了,那肯定会造成计数无法变为0,ext4_ioend_wait当然就总等着了。
再看upstream,唉,很遗憾,已经被Jan Kara修复了,patch在这里

还要感谢鸿蒙(邹巍)同学对我的大力支持,千里迢迢寄过来了Sandybridge服务器,一机在手,调试不愁。能亲手插拔硬盘,才能发现这样的问题,以后才能多多方便大家。

kernel和OS跨公司交流

今天和百度、腾讯做kernel和OS的同学交流了一下,不算特别正式的技术交流,就是互相说说最近一年的工作和收获。

文件系统这块,阿里和百度都遇到了ext4在快写满盘时append写很慢的问题,原因是ext4会扫描整盘的group descriptor来寻找free block,造成大量的io读。目前还没有upstream的解决方案,临时的解决方案可以把group descriptor直接保留在内存不释放。
存储上,百度已经“去raid化”,将硬件的细节尽可能多的暴露给应用,说白了,能应用或者用户态library解决的问题,就不用硬raid或软raid方案,这点跟我们不一样,他们是不用mysql,我们是大量用mysql,要让mysql去支持多盘位自动负载均衡和数据恢复,估计不现实,对于DB,至少目前还是用传统一些的raid方案比较合适。百度用的sata盘居多,用SAS卡而不用硬raid卡(如前所说)。我乘机问了一下百度的”把硬盘槽位和盘符绑定“的方案,他们表示可以公开原理细节,嗯,还是比较开放的,感谢他们。不过硬盘坏盘后read/write系统调用超时的问题,他们也还有panic的bug,看来工作还不是十分完美,还要继续做。
腾讯的同学也在做软raid,不过主要集中在磁盘的软raid工作上,由于他们用的是upstream的2.6.32,遇到不少性能bug,有一个性能退化bug还是在cfq上的,好在我们偷懒用的是rhel-6u的2.6.32,目前还没有发现磁盘软raid有性能瓶颈。

虚拟化是个大头,每家公司都在做,阿里和腾讯的虚拟化主要用xen,而百度用的是kvm,据百度的同学说,他们本来想上kvm后,修几个大bug让其稳定的,结果上去几个月,一个bug都没有,看来redhat在kvm上花了不少功夫,想想也是,做企业软件市场的,kvm虚拟化方案正如火如荼,你卖linux发行办才赚几个钱?卖虚拟机集群方案就来钱得多了看,redhat想来测得是非常仔细,bug非常稀少。像阿里的T4这样用lxc做container的好像就我们一家,其它公司还是选用虚拟机来做,毕竟我们是私有云方案,定制化会多一些。百度还有同学在研究openstack。
来自百度谢广军同学的补充:”百度也用类似lxc的container技术来做内部的集群操作系统,而且对lxc的使用也不是所有的都用,基本只用到cgroup以及container目录相关的东西。xen/kvm主要是开发测试或者对外云。”
来自@rony_85同学的补充:“腾讯也有使用lxc的container技术来做内部云,现在在qzone业务中用的很多,规模应该比你们t4大很多“,看来lxc可以继续搞搞。

内核的网络部分,我是懂得很少,粗略听来,不管是百度还是阿里,主要的大头是客服和调参数优化(李雨同学很辛苦:),这边也有tcp friends和openflow等工作,也还有SDN相关的研究。


kernel和OS交流
参会同学合影

腾讯原先的OS组现在调了很多去深圳做虚拟化相关的工作,北京就留了两个人。这个事,很有代表性,现在kernel方面的工作,都在朝虚拟化集中,如果你还在修ext4的bug、修vfs的bug、修io层的bug、甚至是做“分布式文件系统”,那么你肯定会比较寂寞比较冷清比较被忽视,但是如果你在给xen或者kvm修bug、或者你说你的“分布式文件系统”是“面向对象的“,适合存”虚拟机镜像“,那么恭喜你,你成功的傍上了“虚拟化”这个“大款”,身价大涨,会有人和公司来找你的 🙂
没办法,虚拟化是个大潮,你顺着它还怕赶不上浪头,岂敢逆着?

Ext4 Workshop 2013 总结

作者:刘峥

2013年04月17日,Ext4 社区的开发者举行了一个讨论会。主要讨论目前 Ext4 文件系统中出现的问题及解决方法,以及后续的开发计划。本文章汇总了本次会议的内容。

在这次会议中,主要讨论了如下内容(每个话题中讨论的内容包括但不限于话题本身):

  1. write stall 问题
  2. 3.10 merge window 的相关情况
  3. 关于 Ext4 stable/long-term tree 的维护
  4. extent tree layout 修改
  5. bigalloc 特性的改进
  6. Online Fsck 特性的开发
  7. data=guarded 和文件系统延迟问题的优化
  8. 不同挂载参数的选择
  9. Ext4 针对不同设备的优化

与会人员:

  • Ted Ts'o (Ext4/JBD2 Maintainer, Google)
  • Jan Kara (EXT2/3/JBD Maintainer, SUSE)
  • Eric Sandeen (Red Hat)
  • Mingming Cao (Oracle)
  • Tao Ma (Tao Bao)
  • Lukas Cerner (Red Hat)
  • Zheng Liu (Tao Bao)
  • Darrick Wong (Oracle)
  • Mel Gorman (SUSE)
  • Daniel Phillips

1. write stall 问题

这一问题最初是由 MM 内核开发者 Mel Gorman 报告的,他在测试内存管理的补丁时,发现 Ext4 文件系统的交互响应比较差,延迟很高。通过观察发现是由于 do_get_write_access() 函数中会阻塞在 lock_buffer() 上,造成延迟较大。

Ted Ts'o 提出了两种解决方案:

1) 在调用 do_get_write_access() 时避免 lock_buffer;

2) 整体修改 JBD2,自己管理 buffer_head,从而降低延迟。

由于第二种方案太过复杂,短期内很难完成,所以目前打算先优化 do_get_write_access() 函数来降低延迟。同时,在刷新 metadata 时,通过加入 REQ_* 标记来避免优先级反转问题,提高响应速度。

 

2. 3.10 merge window 的相关情况

最近马上要开始新一轮的 merge window 了,所以 Ted 说明了一下目前的进展,他目前还在进行各种测试。Jan Kara 说他通过 xfstests 测试发现 data=journal 模式下第68项测试失败。Ted 则抱怨了一下 xfstests 没有支持 local group,造成每次测试都要手工指定测试项目。

Lukas 讨论了他关于优化 invalidatepage() 的补丁,Jan 表示会 review 代码。Ted 则说这个 merge window 可以考虑把 vfs 层的补丁先合并进来,下个 merge window 再解决 Ext4 专门的补丁。

Jan 则讨论了他关于优化 Ext4 writepage 路径的补丁,Ted 的建议是留到下一个 merge window 再合并。

 

3. 关于 Ext4 stable/long-term tree 的维护

Ted 对于 stable/long-term tree 的维护工作的态度是,目前他没有时间和精力来单独维护一个这样的 tree。目前,对于 Ext4 文件系统来说,如果需要使用较为稳定的版本,可以的选择是 linux stable tree。因为目前所有有意义的补丁会被抄送给 stable@vger.kernel.org,由 stable tree 对应的维护者来进行维护。当然,如果一些补丁不能够简单的直接打到 stable tree 上,则该补丁将不会包含在相应的 stable tree 中。

 

4. extent tree layout 修改

目前 Ext4 中 extent 存储的物理磁盘块的长度是 48 位,所以,可以将其扩展为 64 位以支持更大的磁盘分区。Ted 表示如果可以扩展到 64 位当然是最好的,但是这是一个长期的工作,目前还没有明确的需求需要搞这么大的文件系统。

目前 Ted 认为对于 Ext4 文件系统更为重要的事情是如下几个:

  • 解决 unwritten extent conversion 的问题,从而彻底实现 dioread_nolock;
  • 对 extent tree/map_blocks 函数进行重构;
  • mballoc 代码的重构和改进,包括 buddy bitmap 被很快回收的问题;

 

5. bigalloc 特性的改进

目前淘宝在使用 bigalloc 的过程中发现该特性还有一些不足,比如在使用 cluster (默认64k) 作为磁盘分配的单位时,对于小文件的存储,空间开销偏大。所以淘宝的想法是希望能够某几个 block group 按照 block size 来分配文件,剩下的 block group 按照 cluster size 来分配。这样可以尽量减少小文件对磁盘空间的占用。Ted 给出的建议是可以考虑指定一个参数,在格式化的时候,指定前面多少个 block group 通过 block size 来分配。这样做相对比较简单;另外一种更为简单的方法是将磁盘分成两个分区,分别按 block size 和 cluster size 来进行格式化,从而解决这一问题。

 

6. Online Fsck 特性的开发

这一需求也是淘宝目前遇到的实际问题。由于数据库等系统需要尽可能的在线提供服务,所以我们希望能够尽可能的缩短宕机后的启动时间。所以,如果可以实现 online fsck 的功能,则可以尽可能的缩短系统启动的时间,同时保证文件系统不被破坏。目前已知的可以进行 online fsck 的文件系统是 zfs, ffs, btrfs。Ted 给出的建议是可以考虑在分配磁盘块的时候在相应的 block group 上添加相应的标记,表明这个 block group 正在进行磁盘块的分配,在出现宕机后,这个 block group 的数据只进行读操作,所有写操作都会被映射到其他的 block group 中。这样可以尽可能的保证文件系统的一致性。

 

7. data=guarded 和文件系统延迟问题的优化

data=guarded 模式最早是 Chris Mason 针对 ext3 fsync 延迟过大提出的一种日志模式。但是后来由于 ext4 中引入延迟分配 (delalloc) 特性而没有再继续开发,也没有被合并进 upstream kernel。这次提出这个话题,主要是由于淘宝在部署 ext4 的过程中遇到了很多延迟问题。在讨论延迟问题的过程中,Ted 提出了一个长远的改进计划,即通过使用 extent status tree 在内存中进行磁盘块的分配,在 end_io 中再创建日志并修改元数据提交。这样可以极大地缩短日志的持有时间,从而尽可能的避免由于日志提交造成文件系统操作的延迟。同时 Ted 还建议减少延迟的方法是尽可能提前将文件预分配出来,同时尽量将文件的元信息保存在内存中。

 

8. 不同挂载参数的选择

这个话题主要是 Red Hat 和 SUSE 的开发者提出的,目的是减少 Ext4 测试环节的压力,同时由于 Linux 发行版陆续使用 Ext4 内核模块来处理 Ext2/3 文件系统,需要在内核中添加检查代码来确保 Ext2/3 文件系统在使用 Ext4 内核模块时的正确性。

其中比较重要的几个挂载参数是是:

  • indirect-based/extent-based 文件的支持;
  • async_journal_commit参数(该参数将被标记为危险,可能造成数据丢失);
  • data=journal 与 delalloc 的互斥问题

 

9. Ext4 针对不同设备的优化

这一话题主要是围绕目前文件系统开发的优化方向来进行讨论。由于 ARM 处理器在服务器领域的使用,文件系统即需要考虑高端硬件设备的优化,同时还要兼顾这类低端设备的优化。针对高端设备,文件系统可以多使用些资源(如内存资源)来获取更好的性能;同时针对 ARM 这类内存较小的设备,可以减小资源的使用,同时提供尽可能好的性能。

Ted 表示目前 Google 针对 e2fsck/mke2fs 工具是有一些优化的,并且已经放到了 upstream 的 e2fsprogs 中,但是并没有在内核代码中针对不同设备进行优化的想法。同时 Ted 表示目前可能更需要考虑针对 eMMC 设备的优化问题。

 

根据本次 Ext4 workshop,后续 Ext4 文件系统的开发主要包括:

  • extent tree 代码重构
  • map_blocks 函数代码重构
  • do_get_write_access() 优化,解决 write stall 问题(目前 Ted 已经将补丁发出并合并进ext4 dev 分支)
  • 使用 extent status tree 来优化磁盘块分配,减小延迟
  • 修改 extent tree layout 支持更大的磁盘
  • mballoc 代码的重构和优化

关于此前使用 extent status tree 实现 range locking 的问题。由于 Jan Kara 已经开始在 VFS 层实现一套通用的 range locking,因此目前与 Ted, Jan 讨论的结果是暂时先不在 Ext4 中单独实现一个 range locking 了。

未来一段时间,Ext4 的开发将主要集中在已有问题的解决,性能的调优和代码的重构上。暂时不会有新的供用户使用的新特性。

ZFS讲座

今天有幸邀请到@casualfish到公司做ZFS的讲座


zfs

zfs

图为@casualfish和@gnehzuil同学

@casualfish同学长久以来专心研究zfs,理解很深,讲得也很详细很精彩,感谢他的分享!
分享的PPT在这里

1 2 3 4 5 7