最新消息:

CLSF讨论会纪要(一)

kernel admin 3379浏览 0评论
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

转载请注明:爱开源 » CLSF讨论会纪要(一)

您必须 登录 才能发表评论!