博客

杂感

很多年，作为一个中国人，我一直觉得台湾回归的那一天将会是我今生最高兴的日子，但是，随着涉世渐深，我不这么认为了。如今，大三通也通了，国共也相谈甚欢了，一切都在向着好的方向发展，可是，就算台湾如香港那样回来了，又能怎么样呢？没错，美国的台湾牌不灵了，中国在国际上没那么多掣肘了，可是，如果国内还是天天都在过“愚人节”，那又怎么能高兴得起来？

这两年，通过互联网，各种各样的大案发生的（或者说被传播的）频率越来越高了。有人说，它们掀起的声浪很大，平复得也极快，人们很快会将它们忘掉，转而追逐新鲜刺激的。但是我有一个信念，人们并没有真正忘记，而是会在心里逐渐累积起来，直到出现那根压垮骆驼的稻草。

不是互联网干掉它的对手，就是对手干掉互联网。如果执拗而不知变化，它们随着时间的发展必将会势不两立。而互联网是不可能被干掉的，“连接被重置”出现得越多，“伟大的墙”也就越暴露在阳光下，但它是见不得光的，当人人都意识到它的存在的时候，它也就离崩溃不远了。我坚信这一点就跟我坚信千百万年后按需分配的共产主义社会必定会出现一样。

我从来没有像现在这样对中国的未来充满信心。

6月5日，前eyou员工聚会，东直门麻辣诱惑

订座是 xjb 负责的，要去赶快找他报名...

09搜超联赛第一场

2:3 输给了 go2map

作为中卫打满全场，基本上没有给对手从我这里正面突破的机会，就是最后一个失球和门将没配合好

从场面上看，这个比分还算合理，我们完全是依靠板凳的厚度在下半场趁对方体力出现问题打进了两个球

go2map 和两年前比起来主力比较固定，我们还在磨合，期望下场能更好

关于 cgroup (control group)

I/O controller 这篇文章提到了 control group，看起来它是 Linux 内核中一个比较重要的概念，于是去找了找资料，给自个科普科普

最早 control group 是叫做 "Containers" (06年9月)，利用 configfs 作配置.

2. container, 一个进程组，成员共享同样的一个或多个子系统分配限制。containers 是层次的，一个 container 可以 hold 多个 container

它的最可取之处是创建了一个资源分配的框架，其它开发者可以利用这个框架去开发自己的资源分配patch，比如上回提到的磁盘设备。

后来不知道为什么没有采用 configfs，自己搞了一个 container filesystem.

最后在 2.6.24 内核(08年1月)中被正式合并进入主线，被改名为 control group 或简写为 cgroup. 详细介绍在 内核源代码文档目录中的cgroups.txt 。

刚刚进入 2.6.24 的时候，只有 cpusets(绑定cpu/memory node) 和 CFS group scheduling( cpu 带宽分配) 两个资源。2.6.25 又引入了 memory resource.

去搜索一下 cgroup，可以看到有好多有意思的 patch，比如 per cgroup 的 OOM killer，甚至 swap cgroup 等等.

Which I/O controller is the fairest of them all?

简单翻译：http://lwn.net/Articles/332839/

I/O controller 用来调度对存储设备的访问——根据系统管理员的配置，对不同类型的进程指定不同级别的访问策略。它可以避免I/O密集型的访问不合理的占用资源，显然，对于那些运行很多个虚拟机的系统，这个非常有用的特性。但是，现在Linux的主线版本，还没有加入I/O controller.

看这么一张图，是磁盘I/O的过程

首先是请求Virtual block，是设备映射层，比如 MD RAID Layer，把请求映射到真正的物理设备；但在实际请求物理设备之前还要通过 I/O scheduler，它应用某种策略以提高磁盘访问效率，尽量避免来回的seek；最后才是硬件访问.

I/O controller可以在block layer里面（上面这个蓝框）的任意一层实现

【具体技术实现细节就不翻译了】
1. dm-ioband ，在Virtual Block Layer 实现。这里有两个问题，一个是没有用现成的control group 机制；另外就是它的控制是基于进程的，而对于内核的I/O，比如VM管理，它没有对应的策略。于是原作者又弄了一个 blkio-cgroup patch，解决了这两个问题。

它的缺点在于，a. 必须要使用设备映射, b. 对底层的I/O scheduler有影响, c. 没有提供任何 QoS 保证，只是做固定的I/O带宽比例分配

2. io-throttle , 它利用了control group，这样策略参数可以通过 cgroup filesystem来配置。

它的配置模式中，每个cgroup只能联系一个设备，一方面多个设备就必须配置多个group，但另一方面对不同的设备可以配置不同的策略。

一个最有意思的设计是它在I/O请求初始化的地方实现，包括内存管理子系统、文件系统、异步I/O的writeback、块设备处理...这样控制带宽的方法之一是让进程去sleep一段时间，看起来这样做比维护一个块IO队列要强。

io-throttle 的好处在于代码相对来说比较简单，可以通过让进程睡眠的方法来控制流量；它没有真正的 QoS，但在某种程度上有点接近。它的问题在代码侵入性是最强的，涉及的子系统太多，另外它同样会影响I/O scheduler策略

3. io-controller , 解决了上述两个方案共同的缺点——它在 I/O scheduler那里实现了一个基于cgroup的I/O controller。虽然支持所有的主线 scheduler：CFQ、Deadline、Anticipatory、no-op，但看起来好像主要是针对 CFG 做的优化。

它弥补了前两个 patch 的缺点，但它不能针对不同的设备配置策略（这是io-throttel的优点），而且并不是在所有 scheduler 下都可靠工作。

Linux 不太可能引入多个 controller，那它最终会选择哪一个？ 目前看 io-controller 最受青睐，但相信其它两个方案也会继续改进直到最后幸运者胜出

SMPlayer 确实不错

2. 其次是 SMPlayer 支持播放 DVD iso 文件，这样就免去了用虚拟光驱额外转换的步骤

我觉得以后不会再考虑 MPC + ffdshow 这样的组合了

译：4K disk sectors

简单翻译下 http://lwn.net/Articles/322777/

自从 1956 年问世以来，40余年间硬盘变化甚大，但堪称奇迹的是，每物理扇区512字节的规范，一直保留到现在

如今设备商已经计划升级这个规范，生产每扇区 4096 字节的硬盘... why?

因为从电子比特转换到磁比特的过程中，不可避免会发生些错误，术语叫 Signal to Noise Ratio (SNR)。于是在物理设备上对应每个扇区，会尾随一块 ECC 校验区域，见下.

随着磁密度的越来越高，ECC 的需求也越来越大。例：在 215 kbpi(KB每平方英寸)，512字节扇区需要24字节的ECC，到了 750 kbpi 的时候，每扇区就需要40字节的ECC来保证同样的可靠性了。但如果改为4096字节的扇区，只需要100字节ECC就可以...

总之，加大sector是有很大成本好处的。那么设备商们打算怎么推进这个事情呢？

在软件（其实就是操作系统啦）还没有准备好的情况下，硬件制造商会推出 read-modify write(RMW) 技术的 4k 扇区来仿真 512 字节扇区。简单说就是对外的接口看是512字节，读接口仿真比较简单，写一个扇区就是传512字节数据进去，磁盘自己把整个4k的内容都读出来，覆盖对应的512字节数据，然后再写回。。。这种设备在 2011 年将推向市场

（qyb注：考虑到缺省文件系统就是4k分块的话，如果操作系统对这类设备优化得当，性能是反而可以提高滴——因为ECC对比是变少了）

再过若干年主流操作系统都对 4k 扇区优化好了，软硬件就和谐了

评：Scaling Memcached: 500,000+ Operations/Second with a Single-Socket UltraSPARC T2

见： http://blogs.sun.com/zoran/entry/scaling_memcached_500_000_ops

以及顺道去传说开发 scalability patch 的 Trond Norbye blog 看了看，感觉如下

1. SUN 在硬件上是有独到之处的，比如这个 UltraSparc T2 在一颗芯片上做到了 8 核，每核 8 进程——传说 Intel Nehalem 计划开发每核 4 线程的，不过到现在好像还只是每核 2 线程。注意 Intel 的超线程是 SMT 技术（准确的说 hyperthread 只不过是一个技术推广出来的商标而已），UltraSparc 是 CMT，原理有所不同

2. scalability patch 没有在其 blog 和邮件列表上找到，估计应该已经集成到 memcached 1.3.2 里面。。。现在最新版本是 1.3.3，我觉得需要高性能 memcached 的除了 facebook 的版本外，这个 1.3.x beta 也值得考虑

3. Trond 给 memcached 增加了一个引擎接口（ http://blogs.sun.com/trond/entry/memcached_and_customized_storage_engines ），貌似以后开发 memcachedb 啥的只需要把 storage_engine 改成 BDB 或者 Tokyo Cabinet 就成了.

4. 从程序开发调试的角度来说，OpenSolaris 有优势，SUN 在高性能计算方面的积累确实很强。C/C++ 程序员可以考虑是否用它来作工作环境（然后再用 VirtualBox 装个 Linux，哈）。

白社会

搜狐白社会的公司内测大概有1周时间了。我上个 SNS 产品的印象还停留在占座，自从2006年底以来，除了每几个月可能去下 facebook，就没有上过其它的 SNS 网站了。

我猜测白社会的很多元素是来自开心，首页上大概三十条好友相关的活动信息，它们把你淹没，但不至于无所适从；让你焦虑，但不至于烦躁。看好友们像工蜂一样忙忙碌碌，孤独感和疏离感油然而生，于是我也投入到贡献好友消息的事业中...

SNS 和网游一样，不是技术产品，而是文化产品。

但消费它们不过是饮鸩止渴而已。有时间还是把手头《苏菲的世界》看完吧

RAIDcore 4000/5000 的驱动下载

好像玩这个产品的中国用户不多，就见到一个石锅拌饭的blog介绍suse下安装的。不过里面提到的链接已经是不能用。我一开始也是走了一个误区，觉得既然芯片是 Broadcom 的，相比那里有下载，结果找了半天都没找到。

后来发现是收购 Ciprico 的 Dot Hill 在提供后继的支持服务，驱动从 http://crc.dothill.com/ 可以找到。如果是 4000 的卡的话，2.1 or 3.3.1 才支持。到了 4.1/5.0 版本的驱动，就好像只支持 5000 了。

PS: 今天试用了下搜狐的 SNS，没有太多惊艳，倒是被里面流传车东跳槽到搜狗的消息震惊了一下——虽然车东上一个头衔是 CTO，不过我感觉他绝对不 Match 搜狗的 technology；后来一打听，果然是来做产品。