技术

这个 Drag&Drop 是指从桌面环境中拖入文件到浏览器，0.5.21 版本中带了这个功能. 随着 0.5.21 一起发布的，还有另外两个新增的 API

印象中这是第一次 Gears 在 0.x.y 的 y 发布中，升级了新的 API，0.5 的首次发布的 ChangeLog 见 这里

另外很有意思的一点是，Gears 给其它浏览器制作的扩展都自动更新了，但... Chrome 反而还停留在 0.5.19，一点都不 Teamwork，哈哈

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

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

"Containers" 着眼于资源的分配，有两个重要概念：
1. subsystem, 内核可以给进程提供的服务/资源
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 等等.

简单翻译：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 最受青睐，但相信其它两个方案也会继续改进直到最后幸运者胜出

说说两个很少提到的优点
1. 首先是得益于 ffmpeg 对 RV30/RV40 的支持，无须额外的解码器就能看 rmvb 了。
2. 其次是 SMPlayer 支持播放 DVD iso 文件，这样就免去了用虚拟光驱额外转换的步骤

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

简单翻译下 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 扇区优化好了，软硬件就和谐了

见： 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，哈）。

好像玩这个产品的中国用户不多，就见到一个石锅拌饭的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；后来一打听，果然是来做产品。

最近有一个项目，涉及到和别的网站合作，双方通信的鉴权计划是通过 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 这两个封装好的函数。

关于这两种类型的差别有人写的很明白了：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，很容易就搞定了

冒似是在 FreeBSD 的 WINE 下编译的. 看来以前在 Cygwin 里编译老土了. 回头等 Fedora 11 出来后试试它宣称的跨平台编译win32应用的能力咋样