林健的BLOG

一、概述

　　WebHPC 是一款基于Web的高性能分布式计算平台软件，由北京织女星软件技术有限公司研发推广。

二、WebHPC的由来

　　1. WebHPC是基于GOS软件开发的一套基于Web的高性能分布式计算平台软件，目前已经部署在以下单位：

　　* 上海宝钢集团公司
　　* 上海汽车股份有限公司
　　* 上海核工程研究设计院
　　* 上海延锋江森座椅有限公司

　　2. GOS简介：

　　* GOS、CNGrid GOS、VEGA GOS（下面简称GOS），在国家“九五”、“十五”、“十一五”863的支持下，由中科院计算所历时十年，逐步研发完善，具有完全独立的自主知识产权，研发首席科学家：计算所总工、前副所长，徐志伟研究员。
　　* GOS目前部署在中国最大的网格平台：中国国家网格（CNGrid）。目前国内最大的两个“百万亿次”机群：深腾7000和曙光5000A。
　　* “十一五”863的8个网格应用项目要求基于CNGrid进行研发，具体包括：
　　　* 高性能计算化学应用系统
　　　* 科学数据网格及科研应用系统
　　　* 基于网格的铁路货运信息综合应用系统
　　　* 中国中医药科学数据网格服务应用
　　　* 气象集合预报应用网格
　　　* 新药研发网格
　　　* 天体大规模并行数值计算软件平台的研制
　　　* 面向水利信息化的高性能计算与网格应用
　　* GOS目前广泛部署在国内各大高校、科研机构、企事业单位，主要包括：
　　　* 北京大学
　　　* 清华大学
　　　* 山东大学
　　　* 香港大学
　　　* 浙江大学
　　　* 中国科技大学
　　　* 西安交通大学
　　　* 上海交通大学
　　　* 华中科技大学
　　　* 大连理工大学
　　　* 哈尔滨工业大学
　　　* 中国科学院网络中心
　　　* 中国科学院高能物理研究所
　　　* 中国科学院上海药物研究所
　　　* 中国科学院深圳先进技术研究院
　　　* 中国科学院遗传与发育生物学研究所
　　　* 中国科学院北京应用物理与计算数学研究所
　　　* 北京市天文台
　　　* 铁道部郑州铁路局
　　　* 中国中医药研究所
　　　* 国家气象局气象科学研究院
　　　* 甘肃省计算中心
　　　* 上海超级计算中心

三、活动内容

　　为答谢新老客户，北京织女星软件有限公司现推出WebHPC免费使用推广活动，包括：安装配置指导、用户培训、应用集成、方案咨询等。

　　欢迎咨询了解联系：

　　* 产品网站：http://webhpc.vegasoft.com.cn
　　* 联系人：程伯群
　　* Tel: 010-62136556-8004, 13521133296
　　* MSN: chengboqun@hotmail.com

　　刘未鹏同志来京工作半年以来，blog 的更新频率有所降低。那次与他交流，他给我的理由是“输入和输出的关系”，毕竟刚刚来到一个比校园复杂得多的工作环境，需要有一定的时间适应这一状态的转变，而这多多少少会影响他的读书计划。不过，更新频率的降低丝毫不影响博文的质量。他今天的这篇《暗时间》又一次激起了我的反思。
　　我是大四下学期（2008 年 2 月）开始在现在的实验室工作的。那学期有一个有明确的目标——本科毕业设计，因此在实验室的时间大都花在了毕设课题及其相关的工程任务上。回顾那一阶段的技术笔记，几乎都是围绕着“shell”这个中心。现在对自己当时精心构建的一些 tricks 还记忆犹新。接下来的一年，我进入了研究生一年级的集中教学阶段，小部分时间花在教学楼里用来保证一个良好 GPA，而更多的时间仍在实验室完成组里安排的工程任务。任务的驱动也使我始终保持着对具体项目、技术和实现的思考状态。当然，也有一定的时间花在了琢磨自己折腾出来的那些体现小聪明的东西上。然而真正使我体会到“状态切换”的，是从今年 9 月升入研二以后。全职的实验室工作看上去比研一那种既要应付考试，又要做好工程的状态要专一，但全身心融入科研环境之后，需要个人处理的事情反而更多了。这其中最主要的一点便是需要更多的独立思考。因为自己经过一年多的训练，已经基本了解了实验室的项目情况和工作风格，那种“任务式”的工作逐渐减少，而自主权在慢慢扩大。在完成工程任务之外，老师和师兄只会在大框架上予以指导，而明确的研究方向和具体的实施细节则没有人会告诉你——毕竟我们在向着科研人员的目标迈进。在这种环境下，如果思维畅通、灵感涌现那自然是好事；但有时的思维受阻往往让人偏离对问题本身的思考，转而进入一种“元思维”，即“自己应当思考什么”甚至“自己是否应当思考‘自己应当思考什么’”。对于生活状态相对单一的中科院研究所的学生来说，这种元思维占用的不只是暗时间，很有可能已经是坐在电脑前的“明时间”了。这比浪费暗时间更令人担忧——一方面可能会想：有时间瞎琢磨这些务虚的东西，还不如多读几篇论文、多做几个实验呢；另一方面又会担心：不能把自己变成漫无目的的数据处理机，要想想怎样更加有效地利用时间、服务于自己的发展道路。
　　因此，意识到暗时间的宝贵并不难，但用什么样的思维来填充暗时间则是一个因人而异的抉择。我比较相信“机会只偏爱有准备的头脑”，但问题也常常出现在这个“准备”上。对“准备”有不同的诠释，可以得出截然不同的结论。我赞同《把时间当作朋友》开篇对所谓“聪明学生基于投资——收效的时间决策”的批判，相比切切实实的努力，那种功利导向的元思维是无意义的状态切换。但什么才是有意义的元思维？是笑来老师的心智控制观或刘未鹏的元学习理论吗？可能皆有之。但我们需要的，也许是更适合自己实际心智水平的、在务实的事务之间决策的元思维。
　　话是这么说，但这种元思维仍然是一个抽象的、空虚的概念。考虑自己每天对暗时间的应用，似乎与思考这一问题的过程本身有“分形”似的相像——在大的状态转移中嵌套着小的状态切换；在低频的思维起伏中包含着高频的意识波动——就差计算一个自相似因子了。意识到这个问题很重要，因为这意味着一种低效。元思维也是一种有输入才有输出的过程，而它的输入应当是其它务实的思维过程及其对应的实践活动。想大脑之所想，及自身之所及，调整元思维在暗时间中所占的比例，或许才是适合自己的一种时间利用方式。

　　参加了多次 Beijing Open Party，熟悉的面孔也越来越多。昨天的活动我去得比较晚，到场后发现又一次牛人云集。IT 民工圈、出版界的活跃人士不用多说，还有见识了传说中神侃的 o6z，听其大谈人类社会。这次西乔也贡献了话题，内容不错，可惜听上去没有她的 tweets 那样活灵活现。
　　说说最惭愧的一件事：以前与周筠老师在 Gtalk 上聊天时，她就提到过她的弟弟周奕；昨天见到周奕老师并与之短聊之后，我也没有意识到这个周奕就是我中学时就从《大众软件》之类的杂志上有所耳闻的、中国共享软件界先驱人物之一的周奕。这一信息是今天在 twitter 上发现并确认的。其实，周筠老师的 blog 上已经多次提到过她弟弟的传奇，可惜我在浏览别人 blog 的时候，往往只对技术内容有深刻的印象，而人情世故什么的则一带而过，这方面以后一定要警觉一点。周奕老师向我询问了计算所胡伟武研究员和体系结构实验室方面的一些工作，而我却没有抓住机会向牛人请教一二。要知道，我也是周奕老师的成名作品《理德轻松排版》的早期用户（可惜是盗版），作为 Abandonware 收藏者，我手头还有一份能启动但无法正常使用的轻松排版 2.00 的拷贝呢（见截图）。

　　历史归历史，人还是要生活在实现中的。周奕老师抓住了共享软件的时代机遇并为之孜孜不怠，而我们要想在信息产业的变革时期有所作为，有必要具备周奕老师那样敏锐的眼光和实干的精神。

　　Btrfs 凭借着其优良的可伸缩性和诸多有用的特性，有望成为 Linux 下一代文件系统。目前它已被纳入主流内核支持，接受用户的实验性（Experimental）使用。
　　今年 2 月 hutuworm 给出了一篇《Ext4 ReiserFS Btrfs 等七种文件系统性能比拼》，他是在 2.6.29-rc3 内核上使用 IOZone 3.318 做的测试。Btrfs 官方 Wiki 也给出了一些第三方测试数据，基于的是 4、5 月份的版本。官方 Wiki 同时指出他们在不断解决这些测试中所发现的问题和瓶颈。这几天我也对 Btrfs 进行了一些测试，并针对某些新特性进行了研究。我的测试基于 2.6.32 内核，使用的工具是 IOZone 3.327，对比对象为 ext3 和 ext4，机器配置为 2 * 4Cores Xeon 2.0G / 8G Memory。从测试结果看，性能方面，Btrfs 在 CPU Cache 区和 Buffer Cahce 区较好，在 Disk I/O 区不如 ext3/ext4（所谓三个区的划分参考 IOZone 文档）；可靠性方面，Btrfs 仍有待加强。下面简述我的几条观察（详细数据省略）。

./iozone -Rab output.xls -g 16G

./iozone -Rab output.xls -s 16G -r 2M

tar cf *.tar *; tar jcf *.tar.bz2 *

　　性能方面：
　　1．CPU Cache 区和 Buffer Cahce 区的 read 吞吐率，Btrfs、ext3、ext4 相差不大。
　　2．CPU Cache 区和 Buffer Cahce 区的 write 吞吐率，明显地 Btrfs 优于 ext4 优于 ext3（tar 测试检验了这个结果）。
　　3．Disk I/O 区的 read 吞吐率 ext3 占优，write 吞吐率 ext4 占优，而 Btrfs 两方面均劣于 ext3、ext4（与 hutuworm 的结论类似）。
　　4．三个文件系统对于小于 CPU Cache 区的小文件，都有“文件或记录过小时读写性能变差”的问题。其负面影响程度 BtrFS 大于 ext4 大于 ext3。
　　而可靠性方面，常规的读写校验并没有出现问题，但在测试 Copy on write（COW）特性时，先后遇到两个错误：
　　1．最初使用 2.6.31-15 内核测试，出现了克隆文件与原始文件计算 MD5 有可能不一致的问题。开发人员回复说这个 bug 已经在 2.6.32-rc 以后的内核中修复。升级内核后此问题得以解决。
　　2．目前使用 2.6.32 内核测试，发现同时读写原始文件和克隆文件，有可能致使 syslogd 出错、文件系统没有响应。现在我还没有得到可靠的答复，但相关回复者基本怀疑是竞态问题。
　　有关 Btrfs 其它的高级特性我还没有详细测试。正在使用或打算使用 Btrfs 的朋友，也欢迎与我交流。

　　出于实验和使用 Linux 内核某些新特性的需要，我要在 Dell PowerEdge 1950 服务器上安装最新的内核，而且必须是 2.6.32-rc 以后的版本。由于服务器硬件的特殊性，这一过程费了一番周折，最终在 @Sisyphusliu 师兄的帮助下搞定，记录如下。
　　服务器上已安装的操作系统是 CentOS 5.3，软件栈的需求使之不能用别的发行版替代。保守的 RHEL/CentOS 5 系列的软件源上最新的内核是 2.6.18-164，因此只能从 Linux Kernel 官方获得我们所需的内核，自行编译安装。
　　在 Kernel.org 下载当前最新的 2.6.32-rc8 内核，将原有内核的 config 文件复制过来，重新 make menuconfig，加入我们需要测试的新特性，然后编译、安装，这一过程顺利。但在系统重启之后，initrd 中的 init 脚本却报出“mount: could not find filesystem '/dev/root'”的错误。看来新内核没有成功挂载本地根文件系统，所以我们仍改用旧内核启动，开始排查原因。
　　PowerEdge 1950 服务器安装了 RAID 卡，即使只使用一块硬盘，它也会走 RAID 的 Virtual Drive。因此 RAID 卡成了最大的嫌疑。检查新内核配置，与 RAID 相关的选项都已经选中，编译出来的 modules 目录中也存在诸如 raid456.ko 之类的模块，那么是什么地方有所缺失呢？对比旧内核与新内核的 initrd 中的 init 脚本，发现 raid456.ko 之类并没有在启动时加载；新旧内核不同的地方在于：旧内核加载了 dm-raid45.ko 模块，而新内核则没有。对比两个内核的配置文件，发现 dm-raid45 相关的内容只在旧内核中出现，新内核没有相应的选项，也没有对应的源代码。
　　于是我们需要核查 dm-raid45 的身份。google 发现 dm- 系列模块不是 Linux Kernel 官方组件，而是 RedHat 开发的 Device-mapper 模块，是以 patch 方式添加到内核中的。CentOS 5 软件源提供的修改版内核中，已经附带了包含 dm-raid45 在内的 3000 多个 patch，这些在我们下载的标准内核中当然没有。在 dm-raid45 的作者 Heinz Mauelshagen（傻根？）的主页上，提供了 dm-raid45 patch 下载，但均针对的是较旧版本的内核，打在新内核上编译屡屡出错。进一步的 google 使我们惊喜地发现，Mauelshagen 一周之前在 Kernel Patchwork_β 上发布了针对 2.6.32-rc8 的 dm-raid45 patch——尽管他这个 patch 的主要目的是提供一个 xor 算法，但这个版本恰好能为我们实验所使用。下载并运行这个 patch 之后，内核编译通过并生成了 dm-raid45.ko 模块，init 脚本中也自动增加了相应的 insmod 语句。
　　然而重新启动系统后，除了多了几句 insmod 的输出，mount 语句照样出错。难道我们找错了原因？这次不猜了，直接深入 initrd 内部分析吧。我们将 initrd 解包，在 /bin 目录中放一个静态编译的 busybox，并在 init 脚本的 mkrootdev 语句（这一语句创建了 /dev/root 节点）之前插入 busybox sh 命令。将这个 initrd 重新打包后重启系统，即可对 initrd 阶段的执行进行调试。调试时，我们发现 initrd 的 /sys/devices 目录下已经出现了一系列 PCI 设备，用 find 查找，其中有一个正是包含了 sda、sda1 等磁盘和分区的节点。看来硬盘是正常工作的。而在 /dev/ 目录下，却没有出现 /dev/sda、/dev/sda1 等设备节点。看来是 mkrootdev 之前的 mkblkdevs 语句没有生效。我们进入 nash，再次执行 mkblkdevs，发现仍然没有效果。于是试图采用 mknod 命令手工建立设备节点。mknod 所需的主、从设备号可以在类似于“/sys/devices/pci0000:00/.../block/sda/sda1/dev”的文件中找到，其语法也可以参考 init 脚本中的其它几条 mknod 语句。在 nash 中手工 mknod 之后，运行 mkrootdev、mount 仍然没能将本地根文件系统挂载。但改用 busybox 中的 mount，挂载则是成功的，可以访问磁盘文件。
　　于是我们推测，可能是 CentOS 5 中较旧版本的 mkinitrd 及其包含的 nash 与新版本的内核出现了不兼容。因为使用新版内核的 Fedora 中的 mkinitrd 和 nash 早已进化到了 6.0.X 版，而 CentOS 5 中的还是 5.1.19.6 版。CentOS 5 的软件源上并没有更新版本的 mkinitrd，在分析了 mkinitrd 包的依赖关系之后，我们认为 6.0.X 有太多的、较为关键的依赖项（而 5.1.19.6 版的 nash 是静态编译的单个文件）。贸然使用 Fedora 源更新 mkinitrd 有可能造成较大范围的影响，不利于我们软件栈的稳定移植。我们需要的只是 initrd 中的 nash，因此可以从更容易的途径获得。我们从一台安装了 Fedora 10 的机器中复制出 initrd，将 nash 6.0.71 及其依赖的库覆盖到 CentOS 5 的 initrd 中。使用这个 initrd 启动，调试 mkblkdevs、mkrootdev 和 mount 顺利通过，最终 Linux 成功启动，文件系统访问正常。
　　不过仔细观察启动时输出的信息，我们还是发现了两个小问题。一是 init 脚本中 stabilized 语句报错：“Could not detect stabilization, waiting 10 seconds”，经查这是 Fedora 10 上 mkinitrd 的一个 bug，在 switchroot 之后并不影响根文件系统的使用，可以忽略。再者是在执行 /etc/rc.d 下的脚本时，udevd-event 报错：“udevd-event[XXXX]: wait_for_sysfs: waiting for '/sys/devices/pci0000:00/.../ioerr_cnt' failed”。估计这也是旧版工具与新版内核不兼容的问题，udevd 主要用于监听设备的热插拨等事件，在我们的实验环境中一般不会涉及。毕竟这只是一个使用 rc 版内核的实验环境，这个问题暂不予理睬。我们最终需要测试的程序在新版内核上运行通过，效果良好。

更新于 2009-12-06：
　　在我们刚刚取得基本成功的时刻，恰逢 Linux 2.6.32 正式版内核发布，要不在正式版内核上也实验一下吧。既然上面是因为升级 nash 而最终成功的，那么 dm-raid45 有可能不是核心问题所在。因此在编译正式版内核时，我们没有加入 dm-raid45，而只替换了 nash 版本。结果一次就启动成功！看来这个问题真是 nash 引起的。至于 dm-raid45，这个机器使用的是硬件 RAID 卡，对操作系统透明，一般不需要内核支持；而 dm-raid45 是软 RAID 模块（感谢网友指正），对我们的系统来说安装不安装无所谓。

更新于 2009-12-07：
　　今天 google 到了另一种解决方案：编译内核前，在 .config 中设置“CONFIG_SYSFS_DEPRECATED_V2=y”即可。经我们实验，果然如此。究其原因，google 到的答案[1][2]大约是说旧版的 mkinitrd 及其 nash 在内核没有 CONFIG_SYSFS_DEPRECATED_V2 参数时默认使用旧版 sysfs 路径格式，从而在新内核下无法正确访问 /sys 内的硬盘信息节点。