微网站需可靠的网站优化

(翻译 《ZFS On-Disk Specification》， 由于是2006年给出的文档，与当前ZFS系统肯定有很多的不同，但是也是一份相当有帮助的ZFS学习文档)

 

1.1 虚拟设备

 

ZFS存储池是由一个虚拟设备集合构成的。这里面一共有两种虚拟设备：物理虚拟设备（physical virtual devices，也称为叶虚拟设备，leaf vdevs），以及逻辑虚拟设备（logical virtual devices，也称为内部虚拟设备，interior vdevs）。物理设备是一个可写的块设备（比如一个磁盘）；逻辑设备在概念上的一组物理设备。

 

Vdev是通过一个以物理设备为叶子节点的树来管理的。每一个pool都有一个被称为“root vdev”的设备作为这棵树的根。root节点的所有直接子节点（无论是逻辑的还是物理的）都被称为top-level vdevs。下图显示了一个由两个Mirror构成的pool的虚拟设备树。第一个Mirror（标签为M1）有两个磁盘，分别通过“vdev A”和“vdev B”来表示；同样的，第二个Mirror（标签为M2）也有两个磁盘，分别通过“vdev C”和“vdev D”来表示。虚拟设备A，B，C，D都是物理虚拟设备。“M1”和“M2”都是逻辑虚拟设备，由于M1和M2都是root的直接子节点，所以都是“top-level vdevs”。

1.2 虚拟设备标签（Vdev Label）

 

Pool中的每一个物理虚拟设备都包含一个256K的结构体——vdev_label。这个Label描述了这个设备以及同一top-level vdev下的其他所有虚拟设备的信息。例如：对于虚拟设备C，它的vdev label中包含虚拟设备C，D以及M2的信息。vdev label的详细信息在下一节中详细描述。

 

使用vdev label有两个目的：它提供访问pool中信息的入口；另外它还被用于验证pool的完整新和可用性。为了保证vdev label总是合法可用的，我们使用冗余和特殊的更新方式。冗余：pool中的每个物理虚拟设备都有4个相同的Label，同一个设备上的4份是完全相同的，不同设备则是不同的。更新：Label的更新过程中，使用两阶段的事务来更新，这样确保虚拟设备上至少有一个合法的Label。下面详细介绍一下Label的冗余和更新技术。

 

1.2.1 Label<span "="">冗余

 

pool中的每个物理虚拟设备都有4份相同的Label，在更新过程中，这4份Label每一个都可以用来访问、验证pool中的数据。当一个设备被添加到pool中时，ZFS在设备的最前面放两个Label，最后面也放两个Label。下图显示四个Label的分布，N表示设备的总大小，L0、L1为前两个Label，L2、L3为后两个Label。

<span "="">考虑到一般情况下设备的损坏都是一个连续的段，所以要将Label放在两个不同的地方。

 

1.2.2 <span "="">两阶段的事务性更新

 

Label<span "="">的位置是在设备加入pool时就设定好了，因此Label的更新并不能像ZFS对待其他数据那样采用Copy-On-Write技术，也就是说，对Label的更新是直接覆盖原有的数据。但是在写任何数据的过程中都有可能发生错误，为了保证ZFS任何时候总是有一个合法的Label，Label的更新过程被分为两个阶段。第一阶段更新偶数的Label（L0、L2），如果在这一阶段中任何时刻发生了错误，奇数Label（L1、L3）仍然是合法的。在L0、L2更新结束之后，第二阶段则是更新L1、L3。

 

1.3 vdev技术细节

 

vdev label的信息被分成了4部分：8K的空闲空间（Blank Space），8K的boot header信息，112K的name-value键值对以及128长度的1K大小的uberblock结构数组。下图显示了L0的扩展视图。

1.3.1 <span "="">空闲空间

 

ZFS支持使用VTOC（Volume Table of Content）和EFI两种方式来描述磁盘布局。EFI标签并不是Slice的一部分（它有自己的保留空间），VTOC标签必须被写在Slice0的前8K空间内，所以为了支持VTOC标签，vdev_label的前8K空间被保留下来防止重写了VTOC标签。

 

1.3.2 Boot Block Header

 

保留，以后使用。

 

1.3.3 Name-Value Pair List

 

后面的112KB存储描述这个设备以及其关联设备的键值对。关联设备即：同一个top level vdev下的设备。比如下图中的灰色圆内部的A，B，M1三个设备。

所有的键值对都使用XDR encoded nvlists存储。关于更多的XDR encoding或是nvlists请参见 libnvpair(3LIB)和nvlist_free(3NVPAIR)man手册。以下的键值对都被包含在这112K的部分内。

vdev_tree递归地描述与当前vdev相关的vdev的信息。

每个vdev_tree都包含以下信息：

 

1.3.4 uberblock

 

nvlist之后就是uberblock的数组。uberblock是访问pool中数据的入口。任意时刻，只有一个uberblock处于激活状态，所有uberblock中事务组编号最高且通过SHA-256 checksum验证合法的uberblock为激活的uberblock，它类似于UFS文件系统中的超级块。

 

为了能够持续访问激活的uberblock，激活的uberblock永远不会被覆盖。所有对uberblock的修改都是通过写入uberblock数组中的另外一个元素来完成的。在写入新的uberblock时，事务组编号以及时间戳都是在同一个原子性的操作中完成。Uberblock通过循环的方式写入。

 

下图显示两个uberblock。

uberblock技术细节

 

uberblock按照机器的字节模式存储。

 

ub_magic

 

用于表示该设备包含ZFS数据。ub_magic的值为0x00bab10c(oo-ba-bloc)

 

ub_version

 

版本号，与前文中键值对的版本号意义相同。

 

ub_txg

 

ZFS中所有的写操作都是通过事务组来完成的。每个事务组都有一个对应的事务组编号。ub_txg用来表示写入这个uberblock的事务组编号。ub_txg必须大于等于前面键值对中的txg编号。

 

ub_guid_sum

 

用来检验pool中所有设备的可用性。当pool被打开后，ZFS遍历pool中所有的叶虚拟设备计算这些GUID的和，然后与ub_guid_sum进行比较，来验证pool中磁盘的可用性。

 

ub_timestamp

 

当前uberblock写入的时间戳（1970年1月1日至今的秒数）

 

ub_rootbp

 

这是一个blkptr结构体，包含了MOS的位置。MOS和blkptr将在后文中详细描述。

 

1.4 Boot Block

 

L0和L1之后有一个3.5M的保留空间。