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讨论会
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. 设备层肯定不如应用层更了解哪些数据热哪些数据不热，所以交给应用层来做热数据迁移似乎更合理更高效。
coly同学和缪勰同学在画板上讨论btrfs
这几天用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
家里种的，在阳台结了一个小小的苦瓜
有一颗辣椒红了，其它的还青着，但是体型大，看着很有丰收感
从老丈家拿来的稀有的黄西红柿种子，可惜花盆太小，所以结出来的也很小....
这个不是我家里的了，这是公园的垃圾桶，像不像Android的那个小机器人？
