DongHao: 10 2011存档

第二天的主题就轻松一些也宽泛一些

Intel的吴峰光介绍了writeback最近的改进方向。

吴峰光
吴峰光(intel)同学的讲座

以前的writeback是脏页到了一定的比例就开始,以后要改为曲线调节式的。举个例子,以前是脏页的比例到了20%,kernel就开始写回;以后,脏页比例到了10%,kernel就开始偶尔的缓慢的写回,到了20%,kernel开始正常速度写回,到了30%,kernel开始频繁写回,有点自适应的味道。

吴峰光做了一个实验:在一台服务器上,启动10个dd来写硬盘,同时scp一个大文件,会发现scp的流量时高时低,抖动的非常厉害(因为脏页比例一到,磁盘就会突然面临大量的写操作,影响scp的读磁盘操作);使用新patch后,scp的流量很平稳。(这个实验太有说服力了!做集群或做“云”的同学们?你们难道没有遇到过类似“一写大文件,其它的进程都被拖慢”的麻烦吗?)


然后百度的谢广军介绍了百度在存储方面的探索。

在SSD出现之前,2006年,百度就与华为合作搞过SSD卡??用nand flash攒一个。很多坏块管理,擦除平衡(就是脏块合并)都是自己靠软件实现的(真辛苦),为了解决写放大的问题,把每个block的其中一部分用来记log(变override为append)

目前百度有个新的存储方案,就是拿掉kernel,让应用直接存取硬件,广军同学原话“raid卡聚合起来的io肯定不如应用直接分开访问N块硬盘的性能“,所以,干脆不要block层,文件系统层,直接访问磁盘!这个激进方案目前在考察中。


互联网应用很容易遇到一个问题:一台服务器上跑多个应用,这多个应用会争夺资源,所以,怎么隔离它们呢?两个常见方案:用虚拟机,或用cgroup。但虚拟机方案显然有两个缺点:更长的IO代码路径更低的效率(Coly提出);在机房搭太多虚拟机会消耗IP增加运营难度(谢广军提出)。所以,目前cgroup胜出。


最后一个讲座是Intel benchmark team的同学主持的,主要介绍intel对各种硬件各种文件系统的测试。最后,他提出了一个很有趣的看法:随着硬件的飞速提升,很多软件层可能面临消失。比如,SSD出现后,很多互联网公司已经不再使用通用的文件系统而改为自己实现一个简单的,而如果以后PCM出现,kernel里的block层和fs层可能就不再需要了。看来我们两天的讨论主题——储存/文件系统,被这最后一个讲座给直接否掉了 ^_^ 
不过Coly有句话:
“PCM就算出来,那也得三年以后了,这三年,咱们不能不吃不喝呀“


clsf 2011
参会同学们的合影

结语:感谢 百度 和 南大富士通 赞助此次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

这一阵子的工作是在给ext4加feature,就是“让ext4的extent length的单位由block变为cluster“。一边写代码一边加测试用例,这个测试用例我就简单的用shell实现的,就用dd命令来写文件。

顺序写的时候还好,等到偏移写(seek一段再write)的时候出了kernel crash,原因是某个extent的length突然变成了0。一开始当然是怀疑我自己哪里写错了,于是加断点,调试,直到我去南京出差周末在宾馆也在调试(感谢马涛同学提供的虚拟机镜像,不然连不上vpn就没法调了),发现事情很神奇:我的extent开始length是2,dd之后还没干别的呢,length就变了,于是终于给dd加了个strace,一看,我的天,dd自己会做ftruncate!而我还没有实现truncate的新feature

这dd真是体贴得我流泪啊,我一直把它当纯write使啊,没想到dd会“智能“的多加一个truncate操作。去翻了一下dd的代码,只要是 of= 一个文件,dd必然会先truncate之,除非带上conv=notrunc。

看来工具不熟就是误事啊。

附dd用法(seek 8k然后write 8k,不要truncate):

dd if=/dev/zero of=/test seek=2 bs=4K count=2 conv=notrunc 
这几天用shell编程做一个简单的自动回归测试,需要用到shell的函数功能,大约是这样:


sum ()
{
    return `expr $1 + $2`
}

sum 3 4
echo $?        #result


一直用的不错,直到今天加了一个case,echo出来的返回值($?)就不对了,set -x调了一番,加法没错,但echo出来就是不对,最后暴力改改,让返回值变为直接 return 1024,咦?echo的东西变了,于是一番google,找到了这篇

原来shell里面函数的返回值是用的errno,而errno只支持0-255,所以如果返回值太大就返回的不对了。

替代方案是干脆用“全局变量”


RES=0

sum ()
{
RES=`expr $1 + $2`
}

sum 133 244
echo $RES
sum 333 444
echo $RES

十一图趣

| | Comments (0) | TrackBacks (0)

家里种的,在阳台结了一个小小的苦瓜


有一颗辣椒红了,其它的还青着,但是体型大,看着很有丰收感


从老丈家拿来的稀有的黄西红柿种子,可惜花盆太小,所以结出来的也很小....


这个不是我家里的了,这是公园的垃圾桶,像不像Android的那个小机器人?

| | Comments (0) | TrackBacks (0)
老婆:“我去买点东西,你自己在附近逛逛”
于是我开始朝附近的海边走去。
这是一条通往海边广场的路,很宽阔,左手边是一排高高的台阶,台阶下面又是一长排的休闲区,桌子椅子一类的。
我继续朝海的方向走,突然看见了一个大大的飞机尾翼悬在上空,我很好奇,快步往前,一架巨大的飞机映入眼帘,居然是一架运输机,瞧这尾翼的样式,这不是“安”系列的运输机吗?这是哪个型号的呢?我从飞机的后面往前走,看见了左边机翼上挂着两个大大的发动机,心里想:喔,一边两个,应该是“安-124”,如果没记错的话。
太奇怪了,海边广场居然停了一架退役的大运输机。好家伙,安东诺夫设计局的杰作啊,结实的俄国货,我等机械爱好者,当仔细瞧瞧。
刚细看了没几眼(周围雾蒙蒙的,总觉得看不清楚),突然发觉周围有异样,咦?广场上稀稀疏疏的站着一些穿黑衣服的人,好像还带着家伙,该不是黑社会火拼吧。
接着我听到了他们在谈判,不好,我得躲远点,于是我往回去的路上走,靠近那些高台阶。

“砰砰”,枪响了!这帮家伙开打了,我一个箭步朝那些台阶后面跳过去,台阶高高的,我抓着不知道什么葡萄藤安全落在了休闲区。不好,有两个家伙跟着我过来了,不是来追我吧。

过了一会儿,我觉得很遗憾:以前光瞧电视里有,我还从没看过真的“安-124”呢!还没来得及细看就....这帮人你说早不火拼晚不火拼,这会儿耽误我事儿。我又从台阶上来,又朝运输机那边走过去,一个端枪的黑衣人拦住我:“干什么?!”,估计这是留下来看场子的人。
我不客气的回答:“看飞机!“
黑衣人居然一脸的遗憾:“唉~~”,他放下枪,居然也朝飞机那边走过去。
得~~,居然都是机械爱好者,走吧,都过去看吧~!




慢慢的,我醒了....这叫什么梦啊....