*Nix and Win32 Kernel

Dennis Ritchie病逝

C语言和 UNIX 之父、K&R 的"R"，Dennis Ritchie，于2011年10月12日在家中病逝。

Dennis Ritchie 在 Bell 实验室对 Ken Thompson 设计的 B 语言进行了扩展，并以此为基础设计了 C 语言。 C 语言与当时设计操作系统常用的汇编语言相比，提供了更好的可移植性，并成为了 UNIX 系统高可移植性的基础。Dennis Ritchie 做的这些工作是开创性的。这些工作使得我们能够使用包括数据结构、函数等高级语言特性的语言书写程序，并可以很容易地移植到不同类型的硬件上，同时又保持与为不同的硬件手工书写的汇编代码接近的性能。C++ 之父 Bjarne Stroustrup 对于 Ritchie 的工作如此评价：“They said it couldn’t be done, and he did it."。即使在 40 多年后的今天， C 仍然在从嵌入式设备到超级计算机在内的各种计算环境中广泛使用。

netmap

今天 BAFUG 活动， Luigi Rizzo （十年前提出DEVICE_POLLING概念的那哥们） 带来了他在 FreeBSD 上新实作的 netmap。

简单来说 netmap 实际上是提供了一种让用户程序以一致的接口直接访问网卡（收发包且zero copy）的方法。Luigi Rizzo 的测试中，用以 1050MHz 的单核，在很普通的万兆网卡上就可以轻松达到 14.8 Mpps 了，每个包的开销大约是90个时钟周期。

SMB协议 vs TCP的延迟ACK特性

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

• 客户端 (SMB Redirector) 如果启用了 security signature，则必须等待命令处理完成才会发出下一条SMB；
• 服务器端如果启用了延迟ACK，则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

针对桌面系统的一个ULE调度器tunable

在 /etc/sysctl.conf 中加入：

kern.sched.preempt_thresh=224

然后用 /etc/rc.d/sysctl start 或重启系统令其生效。

系统默认的值是 80，表示只有新优先级 < 80 时才允许抢占；224 表示非空闲线程均可以进行抢占。这样做的结果是系统会产生更多的切换，从而改善响应时间（牺牲吞吐量）。对桌面系统来说，这种设置是很有用的。

一个奇怪的移位计算结果

今天 强迫症 朱小瘦同学提到一个非常有意思的问题，一个32bit的无符号整数算术右移32个bit应该得多少？

我们知道算术右移一个bit相当于除2，所以一个32bit无符号整数除以 $2^{32}$，理论上，应该得0。

然而事实不是这样。测试显示在 x86 系统上，一个32bit无符号整数算术右移32个bit之后得到的是原数。例如下面这个测试程序：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#include <stdio.h>

int
main(void /* int argc, char **argv */)
{
	unsigned int a = 0x5a5a5a5a;

	a >>= 32;

	printf("%x\n", a);

	return 0;
}

不启用任何优化的话，编译出来的程序得到的结果是：

5a5a5a5a

更进一步，我们将上面的测试改写为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#include <stdio.h>

int
main(void /* int argc, char **argv */)
{
	unsigned int a = 0x5a5a5a5a;
	int i;

	for (i=0; i<33; i++)
		printf("%x\n", a >> i);

	return 0;
}

ZFS dedup初步测试

最近做一个存储的项目，顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28，硬件是 Atom D510 配合 4G 内存。

折腾了一下 neptune 上的 ZFS

我一直是非常反对重装系统的。从技术上说，今天的折腾并不算是重装系统，不过因为把机器上所有的数据（是的，文件系统全部都拆掉重建了）都重写了一遍，所以还是算做了一次吧。

缘起

在采购 家里的路由器 的时候，选择了 WD 的 AV-25【1】 系列硬盘。我选的那款硬盘使用的是新式的 AF （4kiB扇区）格式。

FreeBSD 使用的主流文件系统 UFS 和 ZFS，以及 ahci(4) 驱动都 直接支持 4kiB 扇区。但是，目前市面上的AF硬盘，为了与先前的 BIOS 和操作系统（主要是 Windows XP）兼容，对于 ATA IDENTIFY 的回应，原先返回扇区尺寸的位置变成了逻辑扇区尺寸，这种做法俗称512e，即硬盘通过固件或其他方式模拟山区尺寸为512字节，并处理相关的回写操作。

以512字节为单位进行读写时，在AF格式的硬盘上是低效的。FreeBSD的 ahci(4) 驱动和对应的 ada(4) 驱动会设置 stripesize 以反映驱动器采用的实际物理扇区尺寸，但文件系统并不直接识别这个尺寸。

对于 ZFS 而言，其扇区尺寸是在创建时以 ashift 值写死的，目前在命令行没有办法指定这个值，也不能在创建 ZFS 之后修改。如果修改内核令其使用 GEOM 的 stripesize 来产生 ashift，对 AF 硬盘则会出现内核得到的 ashift 比先前已经存在的 ashift 大，从而导致 ZFS 无法识别的问题（如果创建 ZFS 时已经使用了更大的 ashift 则没有关系）。因此，必须想办法让 ZFS 在创建时就知道扇区尺寸是 4KiB。

FreeBSD 5.3-RELEASE 时新增了一个调试用的 GEOM class —- gnop。可以用它来封装其他 GEOM 对象，并改变扇区尺寸，方法是 gnop create -S 4096 /dev/gpt/store （此处 /dev/gpt/store 是一个按 4k 对齐的 GPT 分区的 label）。gnop会产生一个新的设备节点，/dev/gpt/store.nop，其向系统汇报的扇区尺寸是我们指定的 4096 字节，而不是驱动器汇报的逻辑扇区尺寸 512 字节。

使用这个设备节点创建的 ZFS 就会采用正确的 ashift 值了。

使用 zdb -C pool名字可以检查 ashift 值：对于扇区尺寸为 512 字节的 zpool，其 ashift 是 9，而我们希望的 ashift 值是12。

gnop节点在系统重启以后会消失，但 ZFS 会记住 ashift，因此并不会导致问题。此处也可以 zpool export，gnop destroy /dev/gpt/store.nop 然后再 zpool import 来验证。

经测试，ZFS在知道正确的扇区尺寸以后，持续写操作的性能可以提高至少一倍。

基于 Supermicro X7SPA-H (Atom D510) 的路由器(3)

📜 历史文件已不具备现实意义

本文介绍的是已经停产的硬件，内容已过时。

之前家里用的那个 Linksys WRT310N 路由器就有相当严重的问题（不排除是DD-WRT的问题），如果连续若干天不重启的话，无线网络的连接有时就会失败。部署新的路由器之后，设置了一个cron任务令其每天早上5:30重启：

30 5 * * * /usr/bin/ssh root@10.253.87.254 reboot > /dev/null 2>&1

当然，执行cron的那个用户需要使用ssh key来登录WRT310N，并事先将key传到WRT310N上面。

由于 FreeBSD 默认会对链路状态的变化进行记录，因此只要查看系统日志就可以知道cron是否真的执行了。

在之前的部分我们讨论过关于功耗的问题。在实际使用过程中，我发现 powerd(8) 对于 CPU 占用的计算是有问题的：它计算的是所有CPU的占用率之和，而比较合理的依据则是占用率最高的CPU的占用率。不过，对 Atom 来说 powerd 能够产生的影响有限，因此如果真在使用Atom系统的话不一定真的需要这个patch。下面这个patch可以让 powerd 更有效地 throttle CPU 的频率：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Index: usr.sbin/powerd/powerd.c
===================================================================
--- usr.sbin/powerd/powerd.c    (revision 213306)
+++ usr.sbin/powerd/powerd.c    (working copy)
@@ -127,6 +127,7 @@
 {
        static long *cp_times = NULL, *cp_times_old = NULL;
        static int ncpus = 0;
+       int newload;
        size_t cp_times_len;
        int error, cpu, i, total;

@@ -151,7 +152,7 @@
                return (error);

        if (load) {
-               *load = 0;
+               *load = newload = 0;
                for (cpu = 0; cpu < ncpus; cpu++) {
                        total = 0;
                        for (i = 0; i < CPUSTATES; i++) {
@@ -160,8 +161,10 @@
                        }
                        if (total == 0)
                                continue;
-                       *load += 100 - (cp_times[cpu * CPUSTATES + CP_IDLE] -
+                       newload = 100 - (cp_times[cpu * CPUSTATES + CP_IDLE] -
                            cp_times_old[cpu * CPUSTATES + CP_IDLE]) * 100 / total;
+                       if (*load < newload)
+                               *load = newload;
                }
        }

对路由器这样的设备来说，当有软件 bug 的时候，我们往往希望系统自己恢复并报告问题，而不是等待用户去用调试器现场调试。想要达到这个目的，可以使用 watchdog 机制。在这款主板上有两个 watchdog，其中系统没有自带的那个 Winbond watchdog 的驱动如下：

对齐操作和非对齐操作

操作是否对齐是一个简单而容易忽略的性能（有时是可靠性）问题。对齐主要是指读写操作不产生不必要地跨越存储设备上原生存储单元的访问，这里的存储单元说的是在访问路径上的任何设备，它可以是外存，也可以是内存，甚至是CPU附近或内建的快取缓存，等等。

FreeBSD的textdump

最近遇到一些奇怪的bug，因为是对恢复时间有比较高要求的系统，所以顺便研究了一下用FreeBSD的textdump来代替更早前出现的minidump的方法。

• ← 上一页
• 下一页 →