【翻译】ZFS - Ondiskformat 第一章 虚拟设备（vdevs），Vdev Label以及Boot Block
(翻译 《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键值对以及128K的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三个设备。
<span "="">所有的键值对都使用XDR encoded nvlists存储。关于更多的XDR encoding或是nvlists请参见 libnvpair(3LIB)和nvlist_free(3NVPAIR)man手册。以下的键值对都被包含在这112K的部分内。
|
属性 |
名称 |
值 |
描述 |
|
Version |
version |
DATA_TYPE_UINT64 |
版本号 |
|
Name |
name |
DATA_TYPE_STRING |
当前vdev所属的pool名称 |
|
State |
state |
DATA_TYPE_UINT64 |
当前pool的状态，pool所有状态有： POOL_STATE_ACTIVE 0 POOL_STATE_EXPORTED 1 POOL_STATE_DESTROYED 2 |
|
Transaction |
txg |
DATA_TYPE_UINT64 |
将这个Label写入磁盘的事务组号 |
|
Pool Guid |
pool_guid |
DATA_TYPE_UINT64 |
pool的全局唯一标识符 |
|
Top Guid |
top_guid |
DATA_TYPE_UINT64 |
top_vdev的全局唯一标识符 |
|
Guid |
guid |
DATA_TYPE_UINT64 |
当前vdev的全局唯一标识符 |
|
Vdev Tree |
vdev_tree |
DATA_TYPE_NVLIST |
vdev_tree使用递归的方式来描述。下文详细描述 |
vdev_tree递归地描述与当前vdev相关的vdev的信息。
每个vdev_tree都包含以下信息：
|
名称 |
值 |
描述 |
|
type |
DATA_TYPE_STRING |
表明vdev的类, 有以下几种类型: disk 叶设备:块设备存储 file 叶设备:文件存储 mirror 内部设备:mirror raidz 内部设备:raidz replacing 内部设备:ZFS在设备替换时使用 root 内部设备:vdev tree的根设备 |
|
id |
DATA_TYPE_UINT64 |
当前vdev在父节点孩子中的序号 |
|
guid |
DATA_TYPE_UINT64 |
当前树的全局唯一标识符 |
|
path |
DATA_TYPE_STRING |
设备路径（仅用于叶虚拟设备） |
|
devid |
DATA_TYPE_STRING |
vdev_tree的设备ID，仅用于disk类型的虚拟设备 |
|
metaslab_ arrary |
DATA_TYPE_UINT64 |
由对象号构成的数组。数组中的每个元素（ma[i]）metaslab对应的空间图的对象号 |
|
metaslab_ shift |
DATA_TYPE_UINT64 |
log2（metaslab大小） |
|
ashift |
DATA_TYPE_UINT64 |
log2（当前top level vdev的最小可分配单元，block大小） |
|
children |
DATA_TYPE_NVLIST_ARRARY |
子节点的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的保留空间。
