CLSF 2012讨论会纪要（二）

第二天，来自淘宝的刘峥介绍一年来ext4文件系统的开发进展。

ext4的bigalloc，增大分配单位，减少元数据，加快硬盘检查和创建大文件的速度。meta data checksum，让文件系统的错误更早更快的暴露出来，有利于数据安全和文件系统本身的稳定，但是打开checksum会造成大约20%的性能损失，这个就看用户的选择了。inline data，将小文件或目录（小于4K）的数据放入inode之中，根据统计，ext4上大约70%的目录都在100字节以内，所以这个特性对小目录众多的应用有较好的性能提升。

NO_HIDE_STALE，当用户用fallocate分配了一个大文件的磁盘空间以后，一旦他开始随机写，由于extent会从UNWRITTEN变成全零，大的extent会被切成很多小的extent，元数据会大量增加，journal会频繁写硬盘，这样性能就大大下降了；现在有了NO_HIDE_STALE，用户可以通过ioctl指定：我在从大文件里读一段内容之前一定会先写入正确的内容，没写过的部分我不会去读，这样，不再有extent的分裂，也没有了频繁的写journal，性能得到了保证。这是刘峥在跟踪TFS使用ext4后性能退化的问题时发现的改进方法。这一方法对像Oracle或IBM的DB2这样的数据库系统也是有效的。

status extent tree，将硬盘上extent tree的信息保留在内存里，这样查找和空间判断都变得简洁了。这一工作还在进行，相关patch还没有merge到ext4里。

做direct io的覆盖写时不拿i_mutex，能减少大文件多线程写时的锁竞争，对于使用SSD的数据库系统来说效果非常明显。

ext4开始支持带meta_bg的在线resize。

来自fusionio的李少华介绍了这一年来在快速存储设备上遇到的性能瓶颈及相应的对linux block层的改进。

虽然fusionio的卡很贵，但是仍有不差钱的公司采用多块fusionio卡做raid的方案（多数是金融行业），之前kernel软raid的很多代码和配置在高速PCIE设备上遇到了问题，比如机械硬盘做raid时默认stripe是512K，但是在fusionio的raid上这一size过大，不能发挥SSD随机读写的高IOPS特性，所以应该选小的stripe，当然，也不能太小，太小会造成request被分割到不同的设备上。少华在测试中发现理想的stripe大小是8K或16K。

少华提醒：SSD读是不影响寿命的，但是写会，所以要尽可能的减少对SSD的写（这大概是为什么很多人用SSD盘来做系统盘，存放可执行文件、公共库等只需读的文件）；在SSD快满时，写操作的throughput会下降（主要是因为SSD自己在做gc），而适时的做trim操作（告诉SSD的firmware某块区域不再需要被使用）可以避免这个问题。

coly问：trim以后的那片区域是能保证read全零吗？

少华：没有这个保证

少华还提到，由于RAID是将多个设备聚合成一个，这个新设备只有一个flusher进程来写脏页，性能不够。吴峰光说将来有计划实现一个device多个flusher。

大家还讨论到了fusionio（也包括其它一些SSD厂商）的PCIE-flash卡支持atomic write，由firmware加硬件来保证一个写请求要么成功，要么没发生。这是个杀手级的功能，文件系统为了实现写事务，都是用的journal，不仅代码多而复杂，且对性能也有损失。如果firmware支持原子写，那文件系统完全可以把journal拿掉，专心至致的优化磁盘布局了。

其实固态存储对文件系统的冲击还不止这些，比如，SSD里其实有map来记录逻辑存储地址到实际硬件地址的信息（就是FTL，flash translate layer），而文件系统也有记录文件偏移到逻辑存储地址的信息，显然有点重复了，所以fusionio提出了directfs，一个文件一旦创建就给1T的大小，但是这个1T没有任何对应的物理地址，直到用户开始在文件里写了，才利用SSD里的那个map直接把文件偏移映射到物理存储地址，简洁高效，还带点前卫。这是不是文件系统发展的一个方向？

来自IBM的Zhiyong Wu介绍了最近他们在做的在vfs层统计热数据的工作。他们会在vfs层采集数据被读取的频率，以此算出数据的“温度”是热还是冷，并提供给文件系统层去做数据迁移。统计粒度是1MB。Coly认为统计这个对互联网企业来说最大的用处，不是数据迁移，而是找出应用的bug（运转不好的应用会多次读取热数据）。大家觉得统计所有inode的信息太费内存了，最后提供接口，可以统计某几个inode的信息。

我看介绍里有统计热数据的top200，便问这个排序是在什么时候做的，Zhiyong回答说是每次发生io时都会排序。大家觉得这显然太费了，我建议不在内核里排序，直接把数据和它们的访问频率暴露出来，运维人员一个sort -k2命令就可以自己搞定排序的事情 :)

接下来是redhat的Asias He介绍他在virtio里做的vhost-blk。有了host-blk，从guest os来的io请求会被直接map成host上的bio（以前这些guest os来的io会变成QEMU的针对host os的read和write系统调用，相当于走了两遍kernel的io路径）。大家讨论了各个公司的虚拟化方案，现在最热的云计算说白了就是虚拟机集群，xen是企业级用的最多的，一些互联网公司在尝试container的方案以获得最优的性能（如openvz、lxc），而KVM是redhat主推的（在rhel6里已经把kvm设为默认虚拟机，不再支持xen），原因是kvm毕竟是社区比较认可的虚拟化方案，而lxc等container方案安全性不够。

最后由memblaze的LuXiangFeng做业界SSD存储的报告。

memblaze是类似fusionio的国内创业公司，他们对PCIE的SSD设备做了很多软件方面的开发，提供了多种接口，既可以像磁盘一样线性访问，也可以像key/value存储那样直接put/get（这个对互联网应用挺方便的），还可以做raw device操作（比如应用直接去并行操作SSD上的不同channel，或者应用自己去做gc）。对SSD做单线程的读写是无法发挥SSD的高iops特性的，应用应该加大io并行度??或者通过启动多线程读写，或者通过aio来增加iodepth。

所有参会人员合影

结语：感谢 支付宝 赞助此次CLSF讨论会