林健的BLOG

　　回家秀收藏。

　　Turbo Linux 可谓让 Linux 走进中国的功臣之一。Turbolinux 公司较早地致力于 Linux 的国际化，并推出了包括简繁体中文在内的多种语言发行版。早期的中文 Linux 教程，无论大陆版还是港台版，几乎是言必称 Turbo。作为一家老牌国际公司，Turbolinux 至今仍在维护其发行版（目前最新版本为兼容 RHEL 5.4 的 GreatTurbo Enterprise Server 11.3），其在中国的部门则偏重于行业应用与教育培训，而桌面市场风光不再。无论如何，Turbolinux 公司相比诸多乘 Linux 之风而起的公司来说，其转型是平稳而成功的。

　　蓝点 Linux（BluePoint Linux）曾是几个年轻的创业者打造的中文 Linux 传奇。上个世纪末，它凭借着“内核中文化”的理念，与 Turbo Linux 在中文市场一决高下，曾一度拿下大量国产品牌机的 OEM 订单。可惜蓝点的中文化方案最终没有与标准的 i18n 走到一起，创新的思路反而成了技术骂战的导火索。在历经了一系列技术与市场的变故之后，这个曾在 NASDAQ 上市的小公司先是放弃了 Linux 转做嵌入式，继而光环褪去，从人们的视野中逐渐消失。纪念蓝点，纪念那些执着的技术开拓者们。

　　国内涉水 Linux 发行版的大型通用 IT 厂商中，最有名的当数联想了。2000 年，原联想软件事业部一度推出了幸福 Linux（Happy Linux）家用版、服务器版、嵌入式版全线产品，并在自己的部分 PC 产品中预装，以平衡品牌机操作系统的成本与版权。其重要特色之一是将其在 Windows 平台的代表作——“幸福之家”移植到了 Linux 平台。然而已经广泛接受盗版 Windows 的消费市场并不买联想的账，这个幸福 Linux 连同 Linux 版的幸福之家，很快便为 Windows XP 的登台让了路。

　　世纪之交，国家开始重视国产核心软件的研发，一系列项目基金投向了基于开源代码的操作系统。这的确催生了红旗等几个掌握某些领域核心技术、推出了市场认可产品的 *NIX 厂商。而更多的厂商，如中标普华，则依赖于政府和相关行业的订单。还有一些发行版则是昙花一现，比如共创 Linux。在这种大环境下也难免出现少数涉嫌抄袭造假的尴尬案例。国产 *NIX 发行版最终谁主沉浮？技术因素（特别是中文化）早已不是核心问题，大众消费市场的神话也不复存在。这些挂靠国家科研项目发行版，恐怕比拼的是在中国特色软件环境下的做事能力了。

　　其实当年想借 Linux 发家的不只是这些背景各异的厂商，一些盗版者也动起了 Linux 的脑筋。尽管开源且免费，但对于那个时期的国内互联网，速度和费用的劣势还是让盗版光盘抢占了自由软件发行渠道的一席之地。看看手头这张《PC 软件全接触——Linux 工具集》，涵盖了多少你似曾相识的软件呢？

　　历史，就是在这样大浪淘沙。

　　补遗（2010-2-25）：

　　今天幸运地淘到了这款号称是“首套中文 Linux 操作系统”的 Xteam Linux 1.0（中文名为“冲浪平台”）。成立于 1998 年的冲浪平台公司可以说是国内第一家专业 Linux 开发商，其名称显然来源于互联网刚刚进入中国时所流行的“网上冲浪”的说法。Xteam Linux 早已无人问津，不过转型之后的冲浪平台公司目前作为某香港上市企业的子公司，至今仍然存在。这好歹让 Xteam 的名字成为了“先驱”而非“先烈”的代名词。

　　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 内的硬盘信息节点。

　　Dropbear 是一套来自澳大利亚的 *nix SSH 工具集，以体积微小著称，因此在嵌入式环境被广泛中使用。Dropbear 支持 Linux PAM，但直到目前最新的 0.52 版本，它对 PAM 的支持仍极其有限，只能做基本的身份认证（auth、account），不支持会话与密码管理（session、password）。在使用时，我发现即使是 Dropbear 已实现的 PAM 特性也存在一些不大不小的问题，需要自己动手解决。不过作者在 configure 的帮助中已经说明了现在只是“Try to include PAM support”，并且在与 PAM 相关的源代码注释中多次告知用户可以在什么地方 add、edit、hack 一些代码来满足自己特定的需求。我在编译部署 Dropbear 时，为了正常使用 PAM 认证，做了如下工作（基于 0.52 版本）：
　　1．开启 PAM 支持
　　不要以为 configure 时加入 --enable-pam 参数就开启了 PAM 支持，仔细看 configure 输出的最后一句：Now edit options.h to choose features。我们需要自行修改 options.h，定义 ENABLE_SVR_PAM_AUTH 宏，同时将与其冲突的 ENABLE_SVR_PASSWORD_AUTH 宏注释掉，这样 PAM 相关的代码才会被启用。
　　2．修正每次 PAM 会话（conversation）之后立即销毁密码的 bug
　　svr-authpam.c 中的 pamConvFunc 函数实现了将客户端消息传递给服务端 PAM 的会话。为安全起见，第 119 行使用 m_burn 函数将用完的消息中的密码销毁（使用 0x66 字符覆盖）。但我们知道，在一次 pam_authenticate 调用中有可能配置了多个 PAM（pam_unix.so、pam_ldap.so……）陆续调用应用程序提供的会话函数来取用户名、密码，如果在第一次会话之后立即销毁密码，后续的会话就无法正常工作了。因此，需要等待所有 PAM 会话结束之后再销毁密码。我们可以注释掉 119 行；而 pam_authenticate 之后销毁密码的工作在 svr_auth_pam 函数中已经实现，不用新增。
　　3．去除 PAM 会话函数只识别“password:”提示符为密码消息的限制
　　svr-authpam.c 的第 101 行限制了密码消息的提示符为“password:”，但一些 PAM 有可能使用其它自定义的提示符，这使得 Dropbear 拒绝传送密码。事实上像 OpenSSH 等软件只是通过消息的类型为 PAM_PROMPT_ECHO_OFF 来认定其内容为密码，而不在意提示符是什么。因此，我们可以去除此处对提示符的判断，让使用自定义提示符的 PAM 也能与之兼容。
　　4．解决 PAM 和基于 NSS 的用户映射无法同时工作的问题
　　有的应用系统结合使用 PAM 以及 GNU C Library 提供的 NSS 特性实现应用级的用户到本地系统用户的映射。在这类系统中，用户提供给 PAM 的应用级用户名在 NSS 中被映射为本地系统级用户名，用户只持有应用级的密码而不用知道本地系统级的密码。login、OpenSSH、vsftp 等程序对此种需求的支持良好，但 Dropbear 的实现却是首先调用 getpwnam 获得本地系统级用户名（已经由 NSS 映射过的），再用这个用户名去调用 PAM 认证，这就使得 PAM 得到的是“本地系统级用户名+应用级密码”的组件，自然验证失败。我们可以修改 Dropbear 的实现，在 svr-authpam.c 的 recv_msg_userauth_request 函数中保存客户端输入的用户名，在 svr-authpam.c 的 svr_auth_pam 函数中读取前面保存的用户名，而不要使用 NSS 输出在 ses.authstate.pw_name 的本地用户名。
　　所有修改如下，如果你也需要在 Dropbear 中支持 PAM 认证，可以直接打上这些 patch。我有空向 Dropbear 的作者反馈一下吧。

　　前面提到了如何从磁盘映像中挂载或提取指定分区，现在我们再看看如何从含有 LVM 分区的映像中挂载或提取指定的逻辑卷（LV）。由于 LVM 分区内部有自己的盘区（PE）分配方法，因此逻辑卷在映像中并不一定是物理连续的，不能通过找到其偏移地址直接挂载。不过只要本地系统安装了 LVM 支持，就可以使用 LVM 自带的实用工具完成硬盘映像中逻辑卷的挂载。
　　首先查看一下本地系统已经挂载过的物理卷（PV）、卷组（VG）和逻辑卷。我们看到，系统已经安装并激活了 VolGroup01 卷组。事实上 VolGroup01 中的 LogVol00 是本地系统的根分区，LogVol01 是交换分区。

　　实验使用的 centos5-2-gnome.img 是一个安装了 CentOS 并通过 LVM 管理磁盘的映像文件。使用 fdisk 命令查看其分区结构，其中 centos5-2-gnome.img2 是 LVM 分区，fdisk 不能提供 LVM 的详细信息。

　　使用 Linux 的 loop 设备控制命令——losetup：首先用 -f 参数查找一个空闲的 loop 节点；然后通过 -o 参数指定 LVM 分区在映像中的偏移量（参考 fdisk 的输出），将其挂载在空闲的 loop 节点上；最后使用 -a 参数确认挂载成功。

　　再一次查看系统中存在的 LVM 设施。我们看到，映像中的 VolGroup00 卷组已被扫描到，其中有 LogVol00、LogVol01 两个未激活的分区。

　　这个例子中，映像中的卷组与本地已挂载的卷组名称不同，不会出现歧义。但如果映像中的卷组恰与本地已挂载的卷组重名，则可以使用 vgrename 命令修改映像中的卷组名称。

　　使用 vgchange 命令激活 VolGroup00 卷组，再次查看逻辑卷的状态，LogVol00、LogVol01 已经可用。

　　现在便可以使用 lvscan 输出的逻辑卷设备文件名来挂载对应的文件系统了。

　　如果要提取其中的分区，也可以直接对逻辑卷设备文件或 /dev/mapper/ 下对应的设备文件操作。

　　试挂载提取出来的分区。

　　卸载文件系统之后，别忘了卸载卷组和 loop 节点。