ZFS

今天尝试了一下将 zpool 在线转换为 geli 加密卷，失败。这里记一笔。

想法是：将 zpool （RAIDZ）中的一块盘 offline，建立 GELI 卷，然后用新建的 GELI 卷来替换拿下来的盘。

可以在 这里 下载。

和过去一样，风险自担 USE AT YOUR OWN RISK！

和 FreeBSD 9.0-RELEASE 相比的改动：

• 修正了一组 tmpfs 的 bug；
• 针对 nullfs、 devfs 的可靠性改进；
• “skeljail”；
• top(1) 默认显示每个CPU的占用比例；
• 针对 powerd 的多处理器支持；
• 对 IPv4 流量分 IP 进行统计【注意，由于上锁开销，此改动会略微降低IPv4性能】；
• 重启时设置 watchdog；
• 改善 csh 可用性配置；
• 预设将共享内存绑在主存内；
• Winbond watchdog 驱动；
• 对虚拟化环境默认不测试内存；
• 修正 NEW_PCIB 导致某些硬件问题的bug；
• 一系列 ZFS 相关改进；
• 减少 AHCI 上下文切换开销，高负载状态可达 3.8%；
• 一组 VM 性能改进，提高了异步操作以及 msync 情形的性能；
• 改善了 NFS 服务器预取的顺序读性能；
• 等等。

之前用的邮件系统是基于 postfix、Cyrus IMAPd、amavisd-new等软件在2006年搭建的，跑了5年多，作为不折腾会死星人，对这套系统一直有相当多的不满意，举例来说：

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

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

缘起

在采购 家里的路由器 的时候，选择了 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在知道正确的扇区尺寸以后，持续写操作的性能可以提高至少一倍。

主任说：

冗余不做，日子甭过；备份不做，十恶不赦。

以前一直是每天手动给自己的新服务器做备份，最近找时间写了一套脚本来自动完成这个事情。

脚本没啥复杂的，大体的思路是这样：

1. 在源上根据日期命名生成一份新的快照；
2. 将上次备份机器收到的快照和新快照之间的差异 pipe 给 xz，然后再把结果pipe给ssh（使用key验证），传到备份机上；
3. 备份机解压缩、zfs receive之后，如果成功，ssh到源系统上记录自己拿到的那个新的快照日期；

由于是通过 Internet （从AS6939送到AS33651）传递快照，所以使用了压缩。用ssh来完成传输的考虑主要是因为它能够做到互相验证身份。

最近找时间做了一个家用的路由器。用基于 Intel Atom 处理器的解决方案并不便宜（与传统的嵌入式解决方案相比），但因为软硬件都是 x86，因此开发起来会方便一些。另一方面，Atom的计算性能要远高于其他的传统嵌入式方案。

最近几天测试了一下盘很多（具体说是24块盘，其中2块热备的JBOD）的时候ZFS的性能特点。一些结论

a) ZFS的随机读性能比较差（相对于顺序读写）。这一点除了改为用mirror而不是raidz1/z2之外似乎没什么太好的办法。同样多的硬盘做成两组raidz1（11＋11＋2），与做成两块盘一组的11组mirror的pool相比，针对同样的数据集的随机读性能相差可达10倍多，当然，mirror的结果是顺序写性能会差一些。作为副作用，mirror时的读性能可提高大约4倍左右。

FreeBSD从8.0开始支持从ZFS引导系统，因此，可以使用ZFS的快照功能来实现快速部署。

新机器使用LiveFS启动，Fix it，CDROM。

注意：如果您熟悉RAID请不必浪费时间阅读这篇文章。

为什么用RAID-Z/RAID-Z2而不是RAID-5呢？

答案是：RAID-5有一个不可避免的问题，即它必须使用后备电源才能保证写入的正确性。这也是为什么我一直极力反对使用低档RAID卡和软件实现的RAID-5的原因。