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. 设备层肯定不如应用层更了解哪些数据热哪些数据不热,所以交给应用层来做热数据迁移似乎更合理更高效。


clsf
coly同学和缪勰同学在画板上讨论btrfs


相关文章

分类

留言:

关于文章

This page contains a single entry by DongHao published on 10 25, 2011 5:30 PM.

dd命令的新了解 was the previous entry in this blog.

CLSF讨论会纪要(二) is the next entry in this blog.

Find recent content on the main index or look in the 存档 to find all content.