Recently in 操作系统 Category
这是在公司做简单介绍的PPT，只是推广性的梗概，欲知实现细节的看这里 http://lwn.net/Articles/441343/
Ext4 new feature - bigalloc
View more presentations from donghao.
几个月前朱照远同学向我提过一个epoll的疑似bug：
1. 创建一个socket（sfd）并connect到某个server
2. 创建 epoll_create（efd）
3. 将socket的描述符sfd加入efd， 采用ET模式
4. 调用epoll_wait将返回一个EPOLLOUT事件（因为连接成功了）
以上是正常的，但是，此时如果从server来了一个消息， epoll_wait将会返回一个event，这个event包含了EPOLLIN和EPOLLOUT
“照理说”，既然采用了ET模式，EPOLLOUT上次已经出现了，不应该再出现，但是它被EPOLLIN事件给“带出来”了
这看上去似乎像个问题，但似乎也可以理解为epoll的一个特性，所以，保险起见，我发了个邮件给 linux-api 和 linux-netdev 说明了一下这个事儿，希望能得到权威回答。
不久就有两位回邮件了，其中一位是 Eric Dumazet（从git log里看，他提交了很多kernel network方面的patch，应该是很有发言权的），说得很明白:
"Its not true. Same "status" can be delivered several time.
Think about Edge and Level trigger. An event (change of status) is the
trigger.
As soon as on trigger is done, epoll delivers a status.
And your file status is indeed EPOLLOUT | EPOLLIN, since you can read or
write on it.
....
Not a bug, but a misinterpretation of what is an event and what is a
status."
看来正确的理解是：ET模式只保证在边缘条件出现时（上面的例子是从不可读变为可读）从epoll_wait里返回，但不保证fd的event里只有“从不可读变为可读”带来的EPOLLIN。毕竟epoll_wait返回的event是指fd的“状态”，既然这个fd可写可读，那么包含EPOLLIN和EPOLLOUT就不能被认为是有错。
原文：http://kernel.taobao.org/index.php/Documents/kernel_team_internship
淘宝内核组是一只非常年轻的队伍，我们作为开源社区和淘宝的桥梁，一方面基于淘宝的工作负载来改进Linux内核的性能和质量，另一方面也将开源社区的新想法引入到淘宝的操作系统运行环境中。我们在不断改进Linux在淘宝成千上万台服务器上运行的性能和稳定性的同时，也持续努力将我们的工作反馈回开源社区。
关于淘宝内核组的简单情况介绍，可以在这个wiki页面看到：http://kernel.taobao.org
对于我们在内核社区的一些还很初级的工作，在这个wiki页面有一些简单的数字：http://kernel.taobao.org/index.php/Documents/kernel_development_at_taobao
我们和国内、国际的同行一直有紧密的合作，同时我们的工作内容对开源社区也非常开放。在这个小团队工作，可以同我们一起体验如何从线上运行的上万台服务器的实际运行数据中寻找可以改进Linux内核的想法，然后付诸实践并通过实际运行数据来验证自己的工作效果，并最终将代码反馈回内核社区的这个过程。
如果你是在校的学生，对系统软件开发有一些了解，而且有热情投入到Linux内核开发的社区中来，也许你可以考虑加入到淘宝内核组这个小团体中来进行实习工作。我们是非常年轻的团队，但是我们是勤奋、认真和努力的一小撮人。
实习的工作地点在杭州或者北京的办公室，根据大家的意向而定；工作时间要求不短于3个月，每周不少于3天。我们的实习工资很平常，够路费和伙食费。只是希望在这里做过实习工作的同学以后回忆起这段经历会依然感觉很开心。
欢迎有兴趣的同学发邮件到 bosong.ly 在 taobao 点 com ，希望我们能够有缘分在一起度过一段值得回忆的时光。
bosong.ly注：
我们这个团队成立也就不过1年多，很多人都是刚刚起步的新手，我们做的工作，相比行业内的同行来说，从深入、广度和价值上而言，也都非常初级。所以确实是一群小朋友 ^_^
正是因为大家的爱护、支持和鼓励，才让我们工作的更开心，更享受。
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
