选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
以前一直没注意过这个问题，今天在邮件列表看到 Matthew Flemming 发的邮件才知道实际上 C 标准并不保证 sizeof(void *) == sizeof(int(*)(void))。不过，几乎所有的现代系统上这个等式都是成立的。
例外的情况是类似 x86 实模式这类分段的内存模型中，函数指针可能默认是个far pointer（不过话说，现在还有人为这样的硬件写C吗？）；另外据说IA64上也不一样，不过没有办法证实或证伪。
Read more...这次休假前头一天晚上收到了 ISC 发来的安全公告 CVE-2011-1910。我起草完 FreeBSD 安全公告 FreeBSD-SA-11:02.bind.asc 之后就去休假了，这里补上这个漏洞的说明。
无论你是否使用 DNSsec，只要用 BIND 9.x 来做 DNS 缓存解析服务（而不仅仅做Authoritive DNS服务），就有可能受到这个漏洞的影响。而攻击的方法也相当简单，攻击者只要建立一个 DNS 域，令在回应域名不存在的同时发回一个大的 RRSIG RRset，即可触发 BIND 的某处断言令其退出。
由于目前坊间已经出现了针对这一问题的攻击，FreeBSD 安全团队在收到 ISC 安全公告之后立即发布了对应的安全公告和二进制更新。使用受支持的安全分支的用户可直接用 freebsd-update 获得更新，安装之后使用 /etc/rc.d/named restart 重启服务即可。
Read more...APC BE550G 是一种廉价的UPS，支持以 USB 线通知被保护的系统或查询状态。
在 FreeBSD 上可以用 apcupsd 来配合 USB 通知使用。
去年大河发生过一次停电事故，所以买了一个 UPS 来配合自己的机器；今天大河又来了一次大约90分钟的停电，算是完成了对 UPS 的完整测试。
UPSCABLE usb
UPSTYPE usb
DEVICE
POLLTIME 60
LOCKFILE /var/spool/lock
SCRIPTDIR /usr/local/etc/apcupsd
PWRFAILDIR /var/run
NOLOGINDIR /var/run
ONBATTERYDELAY 6
BATTERYLEVEL 8
MINUTES 3
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
NETSERVER on
NISIP 127.0.0.1
NISPORT 3551
EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 1024
UPSCLASS standalone
UPSMODE disable
STATTIME 0
STATFILE /var/log/apcupsd.status
LOGSTATS off
DATATIME 0
FACILITY DAEMON
SENSITIVITY H
WAKEUP 60
LOWBATT 02
SELFTEST 336
上述设置中比较重要的：
其他一些数据：
最近忙得要死，今天看到 谷奥 的 消息 说 Google Analytics 可以抓访问时的速度数据了，于是部署了一下。
另外，十年以后突然跟你要大学专业课介绍的国家真的伤不起。
Read more...今天收到一封奇怪的钓鱼信，它声称来自 Domain Registration of America，准确地说出了我的名字和拥有的域名中的两个，并建议我立即把域名转移到他们那里。
开价是……一年$30。
用这么坑爹的价钱是想提醒我这是钓鱼邮件吗？
当然，这事其实还没完。我仔细看了一下这封信，发现后面的小字写的还是很详细的，或者说，人家只是一个proposal，姜太公钓鱼愿者上钩的意思。这个事情奇怪的地方在于，邮寄的成本并不太便宜，算上人工的话，如果是美国工人做这个事情的话，算上邮费，一封信怎么也得有$1才能邮寄到我这里；另一方面，减去域名注册的成本，两个域名续费一年的利润大概是$45，也就是说，需要至少1/45的人上当才能把成本打平。
把钓鱼信邮寄到硅谷是怎样的国际主义精神啊，不理解，谁能帮忙理解一下这种商业模式？
Read more...住在西海岸的同学可以在 West Coast and Alaska Tsunami Warning Center 这里找到相关的信息，以及对这次本州地震的海啸模拟。
从美国地震局网站上 看，余震仍然在继续中。
另外，今年的 AsiaBSDCon 仍会如期举行。
Read more...最近做一个存储的项目，顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28，硬件是 Atom D510 配合 4G 内存。
初步测试的主要目的是取得一些感性认识而不是进行定量分析。
首先是支持的算法。ZFS默认使用的是SHA256，不做校验；刚开始测试的时候不懂事，开了校验，发现速度慢的没法忍受（需要继续研究到底是为什么，个人评估应该是因为校验本身触发的读操作导致），关闭校验则会好很多。
ZFS提供了一个事先评估dedup效果的方法，使用zdb -S pool名字来看。
为了避免过分dedup导致数据存储可靠性方面的问题（例如，有某块数据实际上在pool中有200个引用，但实际上只有一份，那么一旦那个数据块出问题的话就会导致200份都出问题），可以设置 dedupditto。
在事后可以用zdb -DD pool名字来查看实际的效果。
下面是某pool中实际的效果：
DDT-sha256-zap-duplicate: 1034868 entries, size 440 on disk, 142 in core
DDT-sha256-zap-unique: 3745115 entries, size 461 on disk, 148 in core
DDT histogram (aggregated over all DDTs):
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 3.57M 151G 117G 123G 3.57M 151G 117G 123G
2 908K 27.5G 22.7G 24.3G 1.91M 63.0G 52.6G 56.1G
4 57.1K 1.15G 862M 983M 269K 5.37G 3.84G 4.40G
8 40.5K 436M 228M 320M 428K 4.75G 2.47G 3.43G
16 4.73K 36.2M 20.6M 31.3M 89.2K 687M 387M 591M
32 295 2.37M 901K 1.66M 12.1K 99.1M 36.3M 69.5M
64 100 708K 224K 524K 8.52K 58.6M 19.0M 44.7M
128 20 10K 10K 80K 3.46K 1.73M 1.73M 13.8M
256 13 76K 39.5K 76K 4.77K 26.2M 13.5M 27.1M
512 11 18.5K 13K 48K 8.05K 12.5M 8.90M 34.9M
1K 8 4K 4K 32K 11.8K 5.91M 5.91M 47.3M
2K 6 20K 5.50K 24K 14.1K 44.8M 12.6M 56.6M
4K 3 1.50K 1.50K 12K 15.2K 7.59M 7.59M 60.7M
8K 1 512 512 4K 16.0K 7.98M 7.98M 63.8M
16K 1 512 512 4K 30.9K 15.4M 15.4M 124M
64K 1 512 512 4K 83.5K 41.8M 41.8M 334M
Total 4.56M 180G 141G 149G 6.45M 225G 176G 188G
dedup = 1.27, compress = 1.28, copies = 1.07, dedup * compress / copies = 1.52
过几天找个Fusion-IO来在iSCSI上实际跑些VM试试看。
Read more...今天 Colin 在blog上介绍说 他刚刚修正了一个 TarSnap 重大安全漏洞。简单地说，用来加密密钥文件的AES-CTR实现时，计数器没有增加（正确的实现中计数器应该每次递增），导致在已知明文时能够通过加密块推算出一块数据使用的密钥，并用它来解密余下的数据。
这个漏洞会导致通过某种渠道获得使用受影响的版本（从1.0.22到1.0.27，包含首尾）上传的加密数据的人，在知道其对应明文的情况下能够解密这些数据。
这是tarsnap目前首次发现安全方面的问题，它也再次说明了对于加密代码的安全审计是非常必要的。
PS 漏洞发现者得到了Colin之前承诺的奖金。欢迎大家继续捉虫。
Read more...作弊条
首次创建git库：git svn clone
\[svn代码库到HEAD分支的URL\]\[git代码库名\]例如，对于 FreeBSD，对应的URL为 http://svn.freebsd.org/base/head/
一般来说，从远程svn库复制需要的时间会比较长，也可以考虑首先在本地建立一份镜像，然后直接用 file:/// 去指定。
接下来编辑 .git 中的 config 文件，找到类似：
[svn-remote "svn"]
url = file:///downloads/mirrors/freebsd/base/head
fetch = :refs/remotes/git-svn
对于不同的分支，可以继续添加新的svn-remote小节，例如：
[svn-remote "svn-releng-8.2"]
url = file:///downloads/mirrors/freebsd/base/releng/8.2
fetch = :refs/remotes/git-svn-releng-8.2
添加完之后，用git svn fetch svn-releng-8.2这样的命令来同步对应的分支。
本地开发分支比较简单，只需git checkout -b
\[你的分支名字\]\[源分支\]即可。
如果需要在另一个系统上做开发，则需要一些特别的步骤。
首先是git clone远程系统上的代码库。然后编辑.git/config，其中应该有类似这样的部分：
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = server:/repo/freebsd.git
为svn的branch建立对应的remote：
[remote "svn"]
fetch = +refs/remotes/*:refs/remotes/svn/*
url = server:/repo/freebsd.git
然后git pull，在git branch -r时就能看到远程系统上的git-svn branch了。这个主要是在git merge的时候比较有用。
Read more...我一直是非常反对重装系统的。从技术上说，今天的折腾并不算是重装系统，不过因为把机器上所有的数据（是的，文件系统全部都拆掉重建了）都重写了一遍，所以还是算做了一次吧。
在采购 家里的路由器 的时候，选择了 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在知道正确的扇区尺寸以后，持续写操作的性能可以提高至少一倍。
Read more...