斯巴达第二季

第二天早上先由oracle的刘博同学介绍btrfs的进展。做为集宇宙之大成的btrfs相比xfs/ext4，新功能和改进都非常多。从08年开始btrfs就内置raid5/6了，一直在做性能改进，现在性能已经比multi-device略好5%，估计是md因为引入了新的设备层，所以性能会有小小损失（不过，5%，我个人感觉大了一点）。btrfs是支持snapshot的，但是对snapshot做defrag却是最近才加入的功能，对COW类性的fs来说，这个很好。online device replace这个功能我们争吵了半天，觉得这个功能到底谁需要，跟互联网运维的磁盘更换确实不搭边。去掉了单目录下创建hardlink的数据限制。还做了很多代码清理的工作，但是btrfs还需要多多注释，否则一般人不容易看明白代码。
接下来是一年一度的老问题（反正我从2011年参加clsf就都是这个问题）：btrfs什么时候稳定下来？刘博回答：btrfs已经稳定了，大家开会沟通一致认为，xfs只是btrfs的过渡。于是文卿同学问道：“你能提供我一个btrfs的配置参数，保证我用了这个参数性能最优同时一定稳定吗？“，我以为刘博同学会说”mkfs.btrfs不带任何参数就行“，结果刘博同学回答：”这个你应该问做发行版的公司，我只是开发而已“，看来“纯”软件公司的”纯“开发人员跟互联网公司的开发人员差别还真大（刘博同学，我举这个例子只为说明而已，不是针对你，如果有所得罪，线下请你吃饭赔不是），我们可是要自己backport、自己功能测试、自己压力测试、自己上线测试（能上线测试都是求爷爷告奶奶了）、自己出性能报告、自己出上线测试报告的、自己给出最佳配置和使用方案的，全套都要搞，当然，我们拿的钱比oracle中国（不算美国）的”纯“开发人员多些，这点我不抱怨。

然后是华为的沈灿泉介绍华为正在开发的私有云系统，用到了ocfs2。华为的这款虚拟机托管方案用专用存储设备做后端，前端是很多个跑xen或者qemu的client，ocfs2存的是虚拟机镜像文件和配置文件。华为的同学在使用中发现ocfs2 90%的bug都出在dlm（分布式锁管理）上，公正的说，在IO压力不大，集群里机器增减不频繁的时候dlm工作还好，但是在人造的大压力下问题就多多了。广军同学于是推荐互联网公司人见人爱的zookeeper，但是灿泉说，zookeeper性能不够，因为ocfs2不是整个集群一个master那么简单，它是对每一个文件都要一个锁管理者（一个master），连文件系统的journal都是一个节点一个，靠zk一个个选根本不行，所以还是得用dlm。大家于是说到了kernel里的那个dlm比redhat gfs提供的dlm更简单也更稳定，EMC的彭涛同学还推荐了luster的dlm，也可备选。华为已经向ocfs2社区发了46个patch，其中39个已经被收入。（这patch数还是很高的，难怪我们组今年突然说KPI可以加一部分社区的patch工作，原来是让华为最近一年的社区patch数给眼红的，唉，去年想做upstream不让做，我一年多贴应用的冷屁股贴得我心都冷了突然又说现在可以做了。算了，人生嘛，十有八九都是不赶趟）未来华为的工作是支持scsi的fence命令，通过scsi命令把主机从集群中隔离出来；还有就是集群的writeback cache，使用SSD做cache来缓解尖峰IO的压力（这招，很多文件系统，不管是单机还是分布式的，都开始采用了）。
ocfs2最早是oracle开发的，涛哥在oracle做了四年的ocfs2开发，攒下了厚厚的几百个patch。这种做upstream且不是只修bug的机会，真的很难得。不过之后几个主力开发人员离开了，ocfs2基本处于停滞状态，bug都没人修了，现在华为突然说正在使用且积极的参与开发，确实值得鼓励，开源减少重复工作，复用提高生产力。

Asias He同学讲解了虚拟机方面的IO优化，主要是virtio的改进。virtio-scsi.ko做了中断的合并（这点和网卡的polling倒是很像）。block multi queue在guest机器上的引入也提高了性能。还有discard命令穿越虚拟机到达host的优化。大家提到了discard命令在磁盘上会不会影响性能，coly和我都觉得应该不会，对于磁盘，trim命令其实没有生效，但是fusionio的李少华同学提醒：SATA协议里discard是会清io队列的（为了保证trim后读返回全零的语义），性能会略有降低。少华同学果然是学贯文件系统块设备scsi加sata，一句话我们只能拜服。

LSI的Jeb Tang介绍了公司的一些新产品。LSI其实不光卖SAS/RAID卡，也卖芯片，浪潮华为都用的是LSI的芯片，然后自己设计存储卡。硬raid卡不用说，用DRAM+FLASH+SUPERCAP（超级电容）来保证服务器宕机不丢数据，而且这个DRAM不仅是保证数据不丢，它还能大大减少io的延迟，对于io深度较低的应用，可以帮助其明显提升性能，比如mysql。Jeb提到了：其实对于1T的硬盘，1G的DRAM完全够了，因为大部分应用io深度不会超过8（我表示拜服）。LSI推出了一款带压缩的RAID卡，可以在export卷大小的时候直接报出解压后的大小，当然，对监控的要求就高了。LSI还提供了mmap接口把DRAM设备直接暴露出来给类似DB写日志用，这招狠，文卿同学打算回去就让DB的同学帮忙试试效果。

Fusionio的李少华同学介绍了fast swap的相关工作。linux在内存不够的时候会把部分内存存入swap分区（如果有的话），这个swap分区一般是在磁盘上，现在有了fusionio的高速存储卡，可以把这个swap分区放在高速卡上，这样就可以疯狂的使用内存（比如一些HPC应用，动辄malloc几个TB的空间）而不用担心OOM或者swap造成的巨大性能降低。linux现有的swap代码在高速卡上跑会有很多性能瓶颈，比如pte里‘A'标记和'P'标记分别有两次TLB flush，解决办法是去掉一个或者合并TBL flush;swap先在找cluster是线性的（显然是为了磁盘读取），现在也可以改为更快的算法以迎合SSD了;per-CPU的cluster，更好的增加io合并（我问少华：fusioniio卡也需要合并io吗？少华回答：即使是高速卡，16K的io和4K的io性能差别还是很大的，最好还是略合并一下）;swap代码路径上还有很多锁，像anon_vma的mutex,swap_lock还有swap address sapce lock，现在也慢慢暴露出瓶颈（有高速卡就是好啊，泪奔），少华同学都一一解之。

最后由来自ubuntu社区的汪黎博士介绍他们使用ceph做测试的各种心得。ceph已经很火了，就不介绍了。汪博士在测试各种搭配的local fs后发现：btrfs最快但最不稳定，xfs出过一次io error然后无法mount了，ext4一直正常（文卿听到这里激动得都快哭了，当面表扬啊）。对于此结论，Jeff询问用的是什么版本的xfs，汪博士说是2.6.38的，Jeff说至少要3.10后的内核xfs他才敢打包票说稳定。看来用文件系统还是得有一个稳定的tree和一伙苦逼的维护人员才行啊，不是拿个光盘装上就能放心用的。
汪博士还反映ceph的文件接口出问题最多，块设备和对象接口比较稳定。大家好奇ceph现在最大部署过多大的集群，intel的Zheng Yan同学回答：dreamhost部署最大的是3PB数据，但是节点数不详。汪博士在ceph上做的工作就是将小文件的数据直接放在MDS上，减少网络延时。

CLSF-2013 参会人员合影

PPT: ext4 xfs ceph virtio btrfs

感谢华为和oracle对clsf的赞助，也感谢LSI提供会场和午餐，还要感谢负责会务工作的谢广军和茶水，更要感谢各位参会者的积极参与和热烈讨论，我学到了很多。
当我向彭涛同学询问EMC做为一家存储公司的未来时，他告诉我，EMC的未来不是VNX，不是Symmetrix，更不是Iomega，而是Pivatol和isilon时，我被震动了，我发现干了七年的码农真是白干了，光会码code，不会抬头看看未来，唉，我要好好向彭涛学习，好好的看看这个世界，好好的思考一下将来。