博客

关于 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；后来一打听，果然是来做产品。

Java/PHP/C ... 几种语言 RSA 的互操作

最近有一个项目，涉及到和别的网站合作，双方通信的鉴权计划是通过 RSA 来做。由于可能涉及到不同的开发环境，于是要研究一下各个语言对 RSA 的支持

1. openssl 缺省创建出来的公密钥文件是 PEM 格式的，但 Java API 导入密码只能是 DER 格式，特别是密钥必须用 PKCS#8 编码。这就需要对 openssl 产生出来的文件做一下转换
   • openssl rsa -inform PEM -in rsapriv.pem -outform DER -pubout -out rsapub.der
   • openssl pkcs8 -topk8 -inform PEM -in rsapriv.pem -outform DER -nocrypt -out rsapriv.der
2. 基础算法的标准是 openssl 的：RSA_private_encrypt/RSA_public_decrypt、RSA_public_encrypt/RSA_private_decrypt 这4个函数，因为 PHP 的 openssl 模块也只提供了这 4 个基础函数（不要幻想用非 openssl 模块之外的东西来做 RSA 运算，比如 PEAR 的 Crypt_RSA，速度慢到令人发指）
3. 要注意上述 4 个函数里，可使用的 padding 参数只有那么有限的几种。对应 Java 里面 Cipher.getInstance() 的参数，只能用 "RSA/NONE/PKCS1Padding" 或 "RSA/NONE/NoPadding"（或许 "RSA/None/OAEPPadding" 是对应RSA_PKCS1_OAEP_PADDING，但我没有深究了）。缺省 PHP 里的 padding 是 RSA_PKCS1_PADDING
4. 关于 python... 嗯，直接用 ctypes 就好啦

5. 用 RSA 签名都是首先将文本做一个单向 hash，然后用私钥将签名加密；校验端拿到签名和文本，用公钥将签名解密，对比是否是文本的 hash。openssl 因此封装了 RSA_sign/RSA_verify 来做这个事情。

   • 但 openssl 的几个 NID 哈希算法和标准的sha1/md5好像不太一样，PHP 几乎无法和这两个函数互操作。
   • Java API 中 Signature.getInstance() 倒是可以用 "MD2withRSA"、"MD5withRSA" 或 "SHA1withRSA"，但也不清楚是否可以和 openssl 的 NID_md2/NID_md2WithRSAEncryption、NID_md5/ NID_md5WithRSAEncryption/NID_md5WithRSA、NID_sha1/NID_sha1WithRSAEncryption/NID_sha1WithRSA 对应起来，仍然需要花时间校验。
   总之为了更多语言的互操作能力，我们现在没有用 RSA_sign/RSA_verify 这两个封装好的函数。

道别等于死去一点点

最近在看《漫长的告别》. 不知道别人看 Raymond Chandler 怎么想，反正我读这本书的时候总是想到古龙——酒／朋友／美女，主人翁枪法拳脚地位都一般，但居然和警察黑帮富翁名流周旋到了最后——我觉得古龙一定是受到了他的影响，包括时不时来一句精辟俏皮的警句。

看豆瓣上的书评，刻薄的人说"看在To say goodbye is to die a little.这句话的份上评一颗星."。 我也觉得这句话最棒，不过书里面说这个是法国谚语。作为一个偏执的google索隐教徒，我很快找出原文是"Partir, c'est mourir un peu"，是 Edmond Haraucourt 的诗

再摘一段关于酒的描写：

　　“我喜欢酒吧开门准备做生意的时候。那个时间屋里的空气还凉
爽干净，样样东西都是亮晶晶的，酒保最后一次照镜子，看领带有没
有歪，头发梳得平不平。我喜欢吧台后面整洁的酒瓶，发亮迷人的
玻璃杯和那份期待。我喜欢看人黄昏时喝第一杯酒，放在干净的垫
子上，还在旁边放一张折好的小餐巾。我喜欢慢慢品尝。在安静的
酒吧喝晚上第一杯安静的酒——妙极了。”

　　我跟他有同感。

　　他说：“酒精就像爱情。第一个吻神奇，第二个吻亲密，第三个
吻就变成例行公事了。再下来你会脱姑娘的衣服。”

确实很古龙，或者说古龙很钱德勒，不是？ Alcohol is like love. The first kiss is magic, the second is intimate, the third is routine. After that you take the girl's clothes off.

将 DV Type-1 AVI 转换为 Type-2

关于这两种类型的差别有人写的很明白了：http://www.igenus.org/blog/2006/10/dv.html ...

家里移动硬盘一共4块，其中最古老的已然是 2003 年的产品了，我觉得数据眼看就不太保险，于是买了一个 500G 的移动硬盘，整个五一假期就在家里备份数据(不仅仅是移动硬盘，大概20张左右2003年刻的 SVCD 这次也一并做成 ISO 保存起来)

数据的大头是以前的 DV，有部分采集后还没有压缩的，于是就得先压缩。但有那么10G左右的数据无法用偶的 DV-2-XviD 处理，甚至用 AutoGK 也会报错，后来我上网搜了一下，说是这种错误应该是由于 Type-1 的 AVI 格式导致的，用 GSpot 一看，果然如此

反正得去找转换工具。但 google 出来的转换工具都是死链接，要么就是根本无法转换。最后无意中发现 ffmpeg 可以做这个事情：

ffmpeg -i SRC.avi -vcodec copy -vtag dvsd -acodec pcm_s16le -f avi DST.avi

然后就是上 DV-2-XviD，很容易就搞定了