当前位置：首页 > news >正文

微网站需爬虫搜索引擎

news 2025/7/21 17:52:29

微网站需,爬虫搜索引擎,wordpress社交链接图标,php做简易网站(翻译《ZFS On-Disk Specification》， 由于是2006年给出的文档，与当前ZFS系统肯定有很多的不同，但是也是一份相当有帮助的ZFS学习文档) 1.1 虚拟设备 ZFS存储池是由一个虚拟设备集合构成的。这里面一共有两种虚拟设备：物理虚拟设…

(翻译《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冗余

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

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

1.2.2 两阶段的事务性更新

Label的位置是在设备加入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 空闲空间

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。