选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
最近做一个存储的项目，顺手在家测试了一下实际数据的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...作弊条
例如，对于 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 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...上回书说到通道服务器的问题。在 /etc/csh.cshrc 中添加下列内容，可令系统同时启动gpg-agent和ssh-agent：
setenv SSH_AUTH_SOCK /dev/null/nonexistent
if ("${TERM}" != "su") then
[ -e ~/.gpg-agent.csh ] && source ~/.gpg-agent.csh >& /dev/null
echo UPDATESTARTUPTTY | /usr/local/bin/gpg-connect-agent >& /dev/null || /usr/local/bin/gpg-agent --daemon --ignore-cache-for-signing >& ~/.gpg-agent.csh && source ~/.gpg-agent.csh >& /dev/null
[ -e ~/.ssh-agent.csh ] && source ~/.ssh-agent.csh >& /dev/null
[ -e ${SSH_AUTH_SOCK} ] || ssh-agent -c -t 20m >& ~/.ssh-agent.csh && source ~/.ssh-agent.csh >& /dev/null
endif
启动gpg-agent的作用是在一段时间内不用重新输入gpg的密码。
Read more...主任说：冗余不做，日子甭过；备份不做，十恶不赦。
以前一直是每天手动给自己的新服务器做备份，最近找时间写了一套脚本来自动完成这个事情。
脚本没啥复杂的，大体的思路是这样：
由于是通过 Internet （从AS6939送到AS33651）传递快照，所以使用了压缩。用ssh来完成传输的考虑主要是因为它能够做到互相验证身份。
Read more...我个人比较喜欢复杂的随机生成的密码。这是一个JavaScript的密码生成器，完全裸奔的界面，可以自行设定字母、数字和特殊符号出现的概率（默认是字母=3×52，数字=7×10，特殊符号2×27，或者78:35:27的关系）。
使用方法很简单，设置参数之后按Generate按钮，系统会随机生成希望数量的随机密码。然后从里面挑一个自己觉得容易记住的就可以了。
由于全部计算是在客户端完成（可以自行查看代码来验证），因此可以将其复制到任何支持网页的地方使用（采用任何GPL授权的软件除外）。
Read more...再发一次。
FreeBSD基金会是符合美国税法501(c)3款的非盈利慈善机构，它为 FreeBSD 的开发以及全球范围内的开发者会议活动提供资助，并帮助 FreeBSD Project 的开发人员提供法律咨询。
FreeBSD基金会今年的捐款目标是 $350,000，目前已经募集到$226,066的捐款。即使是小额捐款也可帮助 FreeBSD 基金会，在美国纳税人通常还可在一定程度上抵税。
捐款网址： http://www.freebsdfoundation.org/donate/。
其他信息请参见 捐款将用来做什么、基金会2010年12月公告、如何申请资助、基金会财报。
Read more...在很久很久以前就有人提出IPv4将要用完的事情，然而当时IPv4地址空间还很充裕，而且NAT还没有非常广泛地使用。于是这事说着说着就变成了一个狼来了的故事，不停地有人嚷嚷IPv4地址要用完了，而这个用完的日期则在600天、400天和300天附近的时候反复来回地拉锯了很久。
和狼来了那个故事稍微不太一样的是，喊狼来了的那些人，例如大的IPv6 ISP和运营商已经早早做好了准备，而那些把这故事当做狼来了而毫无警惕的人则只好手忙脚乱地应付了。
阿宅的一大恶趣味是喜欢仅仅因为"Because we can"而去做一些事情，我也是。我自己的网站的第一个DNS AAAA记录是2007年7月31日创建的，而FreeBSDChina.org于2007年8月4日也已经开始在IPv6上提供服务。由于当时条件所限，在当时我能够使用的唯一的测试手段是登录到一台位于北美的有双栈支持的测试服务器来进行测试。到了北美以后，因为这里的住户 IP 地址是很少发生变化的，我开始在家搭建 IPv6 路由，到后来在北美地区托管了一台服务器，基本上一直都是以双栈的方式接入Internet了。目前，我拥有两个/48的IPv6地址段和两个/64的IPv6地址段。
时间过得很快。今年年初的时候我看到了一个报道说 IPv4 地址大约还剩不到1年了，于是开始关注相关的报道。根据 Hurricane Electric 的估算，今天距离 IPv4 中央地址池的地址耗尽还有大约 47 天。中央地址池的耗尽对最终用户并不会产生立即而直接的影响（总有各种各样的办法来减少IP地址的占用，大企业或者ISP可以用NAT，双层甚至三层NAT等技术来减少实际使用的IP，等等），但是无论如何，我们之前所熟悉的那个互联网的日子已经所剩不多了。
Read more...这其实是一个很严肃的话题。
我在酒店或者提供免费wireless访问的地方一般都会拨VPN回家/公司，然后通过那里的路由访问Internet。这个习惯不能完全消除运营商进行的攻击，但能减少能够实施这种攻击的人的范围。
许多地方会提供免费或收费的 Internet 服务给访客，以方便{会议,旅行,占小便宜,蛋疼}等各种心态的人群的需要。但是，这些地方的网络有时会有一些问题，例如，为了方便，往往它们并不会设置任何访问控制手段，或使用公共的密码。
攻击者可以携带一个提供Internet访问的无线接入点，将其配置成与那个公共的无线接入点采用同样的认证方式。例如，这个人可能在隔壁的房间，很明显，在使用那些认证信息时，你的计算机有很大的可能会连接到攻击者提供的接入点。在你的系统看来，攻击者此时具备与运营商相同的地位：他可以劫持DNS【实际上，第一次访问Internet时弹出的那个登录页面通常就是通过DNS劫持来实现的】，替换你访问的网站（比如银行，邮箱，等等），或进行更复杂一些的攻击，例如通过劫持某个子站来进行XSS，等等。
拨VPN回家可以避免受到这类攻击的侵害：你和VPN服务器要互相做身份验证，并且对通讯内容进行加密。
当然，这样做并不能阻止你的VPN服务器的Internet提供者进行的攻击，但是，相对来说，这类攻击要更容易追查（因为你知道应该去找谁）。
Read more...