共 45 篇文章。
一段时间之前我曾经和很多人讨论过使用ZFS作为/的可能性。现在看来，这个也未必真就是一个很好的主意。
目前FreeBSD 8-CURRENT已经完全支持从ZFS启动了（换言之，连 /boot 也不需要了），方法是透过 GPT 分区（我最近MFC了最后一套gpart的补丁回7-STABLE，gpart将在7.1-RELEASE中以一种可用的形式出现）的gptboot。简单地说，配合ZFS v13和支持ZFS的gptboot，FreeBSD就可以从ZFS启动了。针对RAID-Z和RAID-Z2的支持也在计划中。
但是，我认为现阶段使用ZFS做／仍然是风险相当大的事情。
2008硬盘磨损年！
我相信很多人都遇到过硬盘卡壳、掉链子的情况。当然，这篇文档的主旨不是告诉你怎么样可以绕过那些老爷子写的课本上说的金科玉律──重要的数据都应该有备份──如果你的数据最终丢失了，那么我的问题是：你的备份呢？
但是，即使你有经常备份的习惯，有些数据还是会难免出现一些没有及时备份而导致丢失的情况。我的观点是，没有备份计划的数据都不是重要数据，不要等到数据丢失了再去后悔，但是我们显然应该采取各种各样的手段来阻止没有及时备份的那一小部分数据的丢失。
硬盘
大家一起默念：它很便宜！它会坏掉！
是的，实战经验会告诉你，它很便宜！它也会坏掉！不管这个硬盘是来自什么厂商，也不管它是SATA、SCSI、SAS或者是传统的ATA接口，它出现故障只是时间早晚的问题。
为了解决这个问题，人们提出了廉价磁盘冗余阵列（RAID）的概念。例如，使用两块相同容量的磁盘组成 RAID-1 (MIRROR) 阵列，可以在其中任意一块出现问题时，从另一块中取出数据。而如果有至少3块硬盘，便可以组成 RAID-5 （注：还有其他RAID级别可以用3块硬盘组成冗余结构），只损失 1/n 的容量（n为硬盘数量）来得到带冗余的存储，使得存储可靠性得以提高。
除了改善可靠性之外，RAID还可以用来改善读写性能。例如用多块硬盘组成 RAID-0 阵列，可以将读写性能提高 n 倍，等等。我们并不讨论这些RAID级别。
不幸会发生
和很多人已经想到的一样──不要高兴的太早……
带数据冗余的 RAID 的一个基本假设是，磁盘是不骗人的，它有两种状态：好、坏，并且，主机（或RAID控制器）能够可靠地识别这种状态。
很不幸，这句话只对了一半。一块磁盘要么是好的、要么是坏的（这里，“坏的"的定义是读写时会发生任何错误），但是主机未必能够识别这种状态。
更为严重的是，有些时候主机甚至连读出来的数据是否是正确的这件事都不知道！当你发现自己的程序在其它机器上都很正常，但是在某台机器上总是神秘的崩溃的时候，你就要看看是不是那台机器的内存或者其他存储器出现问题了。
This article describes how to install FreeBSD on ZFS from installation CD-ROM, with ZFS as root partition.
PREPARATION
You need to prepare a ‘disc1’ of FreeBSD, as well as a ‘LiveFS’ disc. Also, you should be familiar with daily operation of FreeBSD system administration.
In order to use ZFS on FreeBSD, one has to use FreeBSD 7.0 or better. For better stability and performance, you should have at least 1GB of RAM, and preferably running on a CPU which is capable to run FreeBSD/amd64, fortunately, most modern CPUs does support this.
很久以前有一种说法是，如果你希望学Unix，那么途径之一就是自己写一个Unix内核出来。这么多年以来，其实成功的人只有1个 :-)
不过，想要学习VFS这样的东西，只要写一个FS就可以了。在tmpfs上面跑了两个小时的stress2，系统还是活的很好，当然还有一些问题没有修完，但对VFS的锁的理解又加深了许多。
pointyhat集群的kris老大前天发来了tmpfs的初步测试结果，很振奋。目前，tmpfs的性能在测试用例的环境下已经达到了md+ufs最佳性能的2－2.5倍，并且，得益于在向FreeBSD移植过程中增加的细粒度上锁，tmpfs在多CPU的环境下表现出了非常好的可伸缩性。
Pawel今天正式import了ZFS——Sun Solaris 10引入的新文件系统。
周六、周日两天的AsiaBSDCon正式报告会，内容非常充实，以致于我都没有时间去整理和把一些感想写出来。今天终于准备离开了，现在是当地时间早上1点半。
说说我比较关注的几个presentation。
Brooks Davis做的关于FreeBSD高性能计算集群的报告，讲到了他们在选型方面遇到的一些问题。计算集群主要考虑的成本是能源消耗与性能之比，因此他们采购了一批Intel机器之后，选择了AMD的产品，而新一代集群也许又要选择Intel的产品；早期Alpha的节点，已经基本被x86的取代。另一方面，他讲述了相当长时间的关于高性能计算为何有很多人使用Linux的问题，由于很多人使用Linux，导致很多做高性能计算的人有这样一种概念，如果那不是超级计算机，就一定是Linux——然而，这样一来，FreeBSD的集群就会遇到一些问题，因此，他们完成了一系列MPI及相关的支持系统的支持，并制作了port。总体而言，高性能计算集群中更倾向于采用自动化的任务分配，以降低管理成本；他们对SGE(Sun Grid Engine)和监控工具进行了一系列修改，使其在FreeBSD上运行的效果与Linux相当甚至更好。
从某种意义上说，超级计算中的开发人员和系统管理员，会朝着两个完全不同的方向去思考问题。如何调和两者之间的矛盾呢？其实，这也正是在其他计算系统中经常碰到的问题。
HOWTO: Recover damaged FreeBSD UFS2 file systems with damaged master super-block
Copyright © Xin LI, 2006.
All Rights Reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS’’ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
注意：本文介绍的方法部分，假定读者对UFS文件系统，以及FreeBSD的日常操作相当熟悉；请勿轻易执行本文介绍的操作，本文中的操作，可能导致fsck_ffs(8)无法修正的严重问题。由于在此本人已明确告知读者这一风险，据此，对于由于执行这些操作导致的任何数据损失，本人明示不承担任何责任。
在Pawel Jakub Dawidek的不懈努力之下，目前ZFS在FreeBSD -CURRENT上已经处于主体功能可运行状态了。尽管目前其性能还不如UFS，并且在高负载情况下会出现panic，但patch已经处于可用状态。