CLSF讨论会纪要（一）

10月13日到14日两天参加了在江苏南京召开的CLSF（China Linux Storage & Filesystem）会议，说会议大了点，主要是大家一群对低层存储和文件系统感兴趣的同学（主要来自SUSE,Intel,南大富士通,淘宝，百度）坐在一起“勾兑”一番。

我绝对是文件系统领域的新手，所以尽管尽心记录，肯定还是很碎片，大家将就着看，如发现错误，欢迎狂喷狂问。

第一天先是由南大富士通的李泽帆介绍btrfs这一年来的新进展。

btrfs已经实现了透明的文件压缩。采用LZO压缩算法（zip压缩算法消耗CPU太大），存在磁盘上的是压缩后的用户数据，压缩单位是一个extent（一次压缩最大不得超过160k的数据）；用户在读取时，根据offset找到该读哪个extent，然后从磁盘中读出数据，解压放入page cache里，然后用户即可访问了。这里面的问题就是随机读的性能较差，因为每次读的extent不一样就得每次都解压；所以这主要适合“顺序读，随机写”的场合。

btrfs还支持只压缩某个文件，而不是整个文件系统。用du命令查看btrfs，看到的是压缩后的大小（i_disksize是压缩后的大小，i_size是压缩钱的大小）。

Coly很有兴趣的询问了压缩的实现方法，因为淘宝正在考虑给ext4加透明压缩的特性，以用于读取频繁的hadoop集群。

btrfs还增加了auto defrag的特性，在将page cache写回前先看对应的extent是否可以合并（磁盘块挪到一起），如果可以，则合并后一起写回，这样写回的性能就好得多（连续磁盘块），且同时做了defrag。问题就是用户会发现自己的write调用会产生很多的额外io（在合并extent呢），会比较困惑。如果加上一个mount option，让用户自己选择是否需要auto defrag，则更好。

淘宝的马涛问：btrfs什么时候才能达到product release的程度？

富士通的缪勰回答：即使是必备的btrfsck，也要半年左右才能达到生产级的稳定

马涛：目前是否有一个详细的针对btrfs的性能测试，证明在哪些负载下btrfs的表现比ext4好？

intel的同学回答：从我们初步的测试来看，大部分负载下btrfs都慢一些….btrfs的卖点主要是snapshot等新特性，而且是面对桌面用户的。

马涛：但linux本身就是被服务端用户需求拉动的

大家乐了。

至少目前btrfs还不会很快用于product。

大家随意讨论

suse的jjzhang同学主要讲了分布式存储——这是存储面临的新挑战。

lustre为什么没有很好的继续下去，是因为它没有进kernel mainline，相比较进了mainline的ceph就好得多。

分布式存储基本绕不开分布式锁管理（DLM），很多分布式存储系统虽然是多机器的入口，但是压力全落在了DLM上，结果效率还是很低，关键是要把压力分摊到不同文件上（DLM是针对文件的）。

正好提到了Ceph的后台是btrfs，”如果btrfs不稳定，ceph也无法稳定”（富士通的同学们笑）

jjzhang自己也做了一个开源的cluster ticket manager，网址在 https://github.com/jjzhang/booth

从纯研究的领域看，只要是有投票算法的集群系统，都有scability上限的问题，工业界通常是通过使用多个集群（每个集群有一台机器作为入口）的办法绕开了这个问题。看来，将来会继续绕下去。

然后由淘宝的Coly同学介绍我们在存储方面的优化。

在CDN和hadoop集群上通过调节readahead减少了IO压力，这个是通过仔细的blktrace跟踪和分析来找到问题的，慢工出的细活（工作通常是这样）。

开始在生产环境试验并小规模推行no journal的ext4。no journal最早是google为ext4加入的新特性，很多互联网公司自己已经在应用层实现了备份（比如GFS，HDFS），并不需要文件系统再记日志，所以这是个提高性能的好途径。

我弱智的问：ext4如果mount时带上data=writeback，跟no journal不一样吗？

马涛回答：data=writeback时，meta data还是要进journal的，而no journal就真的是一点日志也不记了

淘宝期望能将snapshot特性加入ext4，用于虚拟机集群（这样虚拟磁盘就可以做快照了）。目前杨勇强同学（中科院计算所）正在为snapshot进ext4 upstream奋战。

目前我们正在测试并加强bigalloc特性，用于存储大文件的集群——比如hadoop。（bigalloc是身在google的Theodore Ts’o为ext4新加的feature,可将文件块从基本的4K一块提高到64k甚至1M一块，patch见http://www.spinics.net/lists/linux-ext4/msg26417.html）

淘宝考虑过使用flashcache，但是它有两个困境：

1. SSD设备正在降价，也许不久后就可以大量使用

2. 设备层肯定不如应用层更了解哪些数据热哪些数据不热，所以交给应用层来做热数据迁移似乎更合理更高效。