Recently in Development Category

今天的话题都是我比较感兴趣的。

开场的Keynote是eBay的Oliver Ratzesberger的 Enterprise Analytics on Demand。eBay每天的数据增量是50TB，而每天的数据处理量是50PB。这个presentation讲了相当多的规划方面的细节。

第一篇 DFS: A File System for Virtualized Flash Storage 介绍的是一个把卷管理（并不完全是：包含了Flash的wear leveling）和文件系统集成在一起的设计。FusionIO公司提供了一种直接在PCIe接口上插的存储设备。类似这样的设计，感觉是未来Flash文件系统必须要走的一条路。

第二篇 Extending SSD Lifetimes with Disk-Based Write Caches 是一个很有意思的设计：现时磁盘的反复擦写寿命要远好于Flash，因此，在磁盘上做一个顺序写入的日志，然后再择机将数据擦写回Flash。不过这篇论文讨论的具体方案还有一定的改进余地。

第三篇 Write Endurance in Flash Drives: Measurements and Analysis 是关于 Flash 寿命的衡量方法。

今天去参加了在San Jose举行的 FAST '10 第一天的 Tech Session，FAST是 USENIX 主办的关于文件和存储技术的学术会议。记上几笔。

开场的Keynote其实讲的还算精彩，不过感觉跟会议本身关系不大（讲的主要是发展中国家的手机等设备的发展），就不介绍了。

Build a Better File System and the World Will Beat a Path to Your Door部分。第一个是本次的获奖论文 quFiles: The Right File at the Right Time ，具体来说是实现了同一份data（文件）的不同view（例如，将其表现成不同分辨率、码流等）的一种通用的存取方法。个人对Semantic File System持保留态度，不过这个talk还是可以帮助拓宽一下思路。

第二篇是介绍在 WAFL 类型的文件系统（具体举例是 btrfs） 中实现倒排索引的 Tracking Back References in a Write-Anywhere File System。具体来说，是在 inode -> 块这样的单向关系基础上，增加了块->inode（包括inode版本、回收时间等）的倒排索引。paper值得看但是性能比较做的稍微有些瑕疵（用做B-Tree的时间去比较在FS中查询的时间，而没有比较建立倒排索引之后更新与在block中插入信息所引起的开销，以及两者对应的查询时间）。

第三篇指出了内存故障可能导致的问题，指出 ZFS 的 end-to-end 检查只能检测出磁盘介质或控制器偶然故障引起的问题，而系统主存中存在的问题则无法发现并可能导致数据损坏甚至系统崩溃，并提出了在 ext2 FS 中增加运行时checksum检查的方案。这篇的试验方法和结论受到了很多人的质疑。

午饭时间。

前一段时间帮一个朋友做了一个非常简单的网址缩短服务，已经上线运行了一段时间，这里把当时设计的一些想法分享出来，等有时间我会把代码也发布出来，程序很简单，用 web.py 做的。

网址缩短服务需要考虑两个问题，第一个问题是如何有效地查询，即，作为约束条件，在访问"短网址"的时候，它必须能够迅速的将结果返回；第二个问题是如何有效地将写操作复制出去。还有一点就是，缩短形成的短网址要真的越短越好。

接口

整个服务包括两个主要接口：一个是请求短网址，输入为网址（作为HTTP回应），输出为短网址；另一个是请求重定向，输入为短网址，输出为到短网址对应的真实网址的HTTP 302重定向回应。

设计

请求短网址的流程大致如下：

首先，检测输入的网址是否有效。

然后，计算输入的网址的 SHA256 散列值（计算时增加一个系统全局的salt值）的 URL-safe base64，并查找此散列串是否已经存在；如果已经存在，但对应的网址不同，目前版本将返回一异常（由于SHA256设计中的雪崩效应，这种情况基本可以忽略）。

如果不存在，则从前3位开始逐字向后取散列串，在查找表中查找到找到相同URL，或找不到结果为止；如果找不到结果，则将目前散列串的子串以及网址插入。

请求重定向的流程大致如下：

首先检测输入是否有效（不超长或超短）。

然后，直接从Berkeley DB中查找字符串对应的URL（实际实现中，将db文件以散列串首个字符命名，以利于未来将负载分散到不同的服务器）。

返回302回应。

未来的改进

目前的设计假定存在 2^0或2^1或2^2 .. 2^6 个节点能够提直接提供转向服务。转向回应信息可以在前端代理上永久缓存，因此可以通过增加前端代理服务器，而不是后端转向服务节点的方式来进行扩展。目前设计中故障转移等机制比较简单（根据SHA256计算出来的优先权值轮转），未来版本需要解决集群的原子提交问题。

目前的设计没有考虑自定义短网址，比如 foo.com/survey 这样的情况。这个问题可通过在长域名表（完整SHA256 base64与URL映射关系）基础上再增加一个查找表的方法来解决。

目前设计没有考虑删除以及禁止访问某些短网址的情况。

什么乱七八糟的东西都往数据库里面硬塞，该做的索引不做，不该做的索引一大堆，这再不慢等什么呢，天理难容嘛......

buffer和cache是两个经常被混为一谈的概念。从直观上说，两者都具备改善系统 I/O 吞吐量的能力，但是这两个概念是有区别的，其提高系统I/O吞吐量的原因也不尽相同。

cache改善系统性能的主要原因是数据访问的 局部性，即，通常应用程序在一段时间内操作的数据集的某个有限的部分，通常是很小的一部分。硬件实现的cache通常会只使用一小块（与主存相比）访问速度很快，但相对比较昂贵的存储部件，并放置于距离CPU较近的位置。

buffer改善系统性能的主要原因是减少不必要的状态切换和设备I/O。由于制造工艺等个方面的原因，系统中不同部件的速度往往是不一样的，一次进行批量的操作（例如，预先读取，或者将写数据凑成一个整数之后再写），往往要比到需要时等待这些操作完成要节省时间，并且有效地降低状态切换导致的开销。

还有一个比较显著的区别是，cache通常是硬件或OS提供，用户程序不需要（多数情况下也没有办法）为其分配存储的机制，通常它在使用者，如用户程序看来是透明的，它属于提供cache的一方而不是其使用者；而buffer往往是由用户程序知道并且与OS共享（换言之，用户程序需要分配一块内存，并告诉OS这块内存将要用于某种操作），或由OS分配，并在主机和外设之间共享（例如网卡的DMA buffer），在使用者看来它通常不是透明的，这些内存往往属于控制内存的程序，如用户程序，或OS，而不是向其传递数据的OS，或硬件。

不过，这个区别主要是传统意义上的cache。最近几年引入的一些新概念，特别是Internet cache并不能用这种方法来区分。我认为最关键的区别其实在于，buffer主要作用是在于减少实际的I/O操作次数，即，将多次操作尽量合并成一次的成批操作，通常其中的数据在操作完成之后，buffer不会被继续使用；而cache的主要作用在于更好地利用局部性原理，减少不必要的I/O，避免代价昂贵（例如，速度很慢）的I/O操作。

感谢 Henry Hu 的帮助。ibus的一些代码在64位系统上有些问题，另外发现预编译的bytecode也有点小毛病，需要手工删除 /usr/local/share/ibus/ui/gtk/ 中的所有 pyc 和 pyo 文件，看来需要找时间看看到底是什么问题了。ibus拼音的效果要好过scim的智能拼音。

最近收到一封邮件邀请我参加一个调查，发现老外对参加代码公开的项目，特别是开源以及自由软件项目的动机总结的很透彻，多少也帮助我更深入地理解了为什么会存在开源和自由软件的分别。

许多参加开源项目的开发人员最初的动机纯粹就是回馈，或者希望自己能够从中受益----例如，他们受益于开源项目（例如，使用了这样的软件，等等），对这些项目进行了一些改进，而另一方面又不希望自己去独力维护一个fork版本，因为这样做比较浪费时间，或从成本上来算不合适，等等。

而参加自由软件的开发人员则是希望社会对其有所回馈。例如，他们会希望别人使用自己的东西的时候能够把改进送回来，等等。

许多人会同时有这两种想法。态度比较强硬的会更倾向于使用自由软件的授权，如GPL；而其他人则会希望使用更宽松一些的授权，如Apache、MIT、ISC或BSD。

我个人倾向于使用BSD和MIT授权。

很多人在一个新产品发布的时候，往往会非常关心这个产品是否发布了相应的源代码。然而，对开发者来说，这毫无疑问是一种本末倒置的关注。

源代码能告诉我们的事情是，一件事情是"如何"去做的，而不是"为什么"要那样做。这事就有点像填写报税的表格，那个表格会告诉你在第1行到第20行每行填写什么数字，然后从第几行到第几行的数字相加，减去第几行到第几行的数字之后写到第几行。而当你想要知道为什么要这样做的时候，税表会告诉你"详见税法某某条"或"详见某说明"，而提供了源代码的产品就不一样了，因为那些说明，往往要么是一些公司的内部机密文档，要么干脆没有。

没有文档是一件很糟糕的事情，但是很多人却会认为，代码可以取代文档。虽然我自己也不太愿意写文档，但是我完全无法认同这种观点。代码可以告诉你"我做了什么"，但是却很难告诉你"当时我是怎么考虑的"，而文档则相反。维护旧的代码，在缺少文档的情况下是代价很高的一件事，因为开发人员在撰写代码的时候认为显而易见的事情，往往在其他人看来并不那么明显，甚至，这些被认为是对的东西很可能其实是错的。显然，代码的同僚复审并不能完全消灭这样的问题，因为很可能两个人水平接近，而撰写文档的过程则会帮助开发人员重新整理思路和思考其中的错误。

我相信，随着不提供文档，但源代码公开的软件的越来越多，明白每一件事在计算机里面到底是如何发生、以及为什么会这样发生的人会越来越少。不重视文档，却单单重视代码，总有一天会酿成为我们这个行业的悲剧。

On Python 2.6 we have a new 'hashlib' module, which superseded older 'md5' 'sha1' modules.

Therefore, importing 'md5' would give the following warnings:

This is quite annoying if you run PlanetPlanet in a cron(8) job and receive e-mail reports. In order to solve that, we can do some simple sed(1) replace over PlanetPlanet's __init__.py:

s/import md5/import hashlib/g

s/md5\.new/hashlib.md5/g

That's it! And PlanetPlanet will now happily work with Python 2.6.

版本控制、持续集成测试、自动化回归测试等等，都拦不住不靠谱的开发人员和盲目引入新特性而不关注可用性和可靠性的架构师。某开源项目真是快让我发疯了，明明都已经第十几个小版本了......

今天 -HEAD 被命名为 FreeBSD 9.0-CURRENT 了（对应的 __FreeBSDversion 是 900000）。从流程上说，这么做的意思是 -HEAD 终于准备解冻进入 slush 状态了（另外，8.0-BETA3应该很快会发布了），基本上之前的一些障碍也都扫清了，目前看来，8.0-RELEASE应该只推后两周左右。。

LLVM 是 Illinois 大学发起的一个开源项目，它到底是什么呢？从字面上看，它是一个虚机系统，然而这又和之前为大家所熟知的 JVM 以及 .net Runtime 这样的虚机不同，它提供了一套中立的中间代码和编译基础设施，并围绕这些设施提供了一套全新的编译策略（使得优化能够在编译、连接、运行环境执行过程中，以及安装之后以有效的方式进行）和其他一些非常有意思的功能。

为什么这个项目很重要呢？对于普通的开发人员来说，LLVM计划提供了越来越多的可以使用、编译器以外的其他工具。例如代码静态检查工具 LLVM/Clang Static Analyzer，是一个 Clang 的子项目，能够使用同样的 Makefile 生成 HTML 格式的分析报告；而对关注编译技术的开发人员来说，LLVM提供了很多优点：