网址查询网站,云彩网站,建筑施工企业安全管理人员考试,福州发布最新通告(翻译 《ZFS On-Disk Specification》#xff0c; 由于是2006年给出的文档#xff0c;与当前ZFS系统肯定有很多的不同#xff0c;但是也是一份相当有帮助的ZFS学习文档) 1.1 虚拟设备 ZFS存储池是由一个虚拟设备集合构成的。这里面一共有两种虚拟设备#xff1a;物理虚拟设…(翻译 《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”来表示。虚拟设备ABCD都是物理虚拟设备。“M1”和“M2”都是逻辑虚拟设备由于M1和M2都是root的直接子节点所以都是“top-level vdevs”。 1.2 虚拟设备标签Vdev Label Pool中的每一个物理虚拟设备都包含一个256K的结构体——vdev_label。这个Label描述了这个设备以及同一top-level vdev下的其他所有虚拟设备的信息。例如对于虚拟设备C它的vdev label中包含虚拟设备CD以及M2的信息。vdev label的详细信息在下一节中详细描述。 使用vdev label有两个目的它提供访问pool中信息的入口另外它还被用于验证pool的完整新和可用性。为了保证vdev label总是合法可用的我们使用冗余和特殊的更新方式。冗余pool中的每个物理虚拟设备都有4个相同的Label同一个设备上的4份是完全相同的不同设备则是不同的。更新Label的更新过程中使用两阶段的事务来更新这样确保虚拟设备上至少有一个合法的Label。下面详细介绍一下Label的冗余和更新技术。 1.2.1 Labelspan 冗余 pool中的每个物理虚拟设备都有4份相同的Label在更新过程中这4份Label每一个都可以用来访问、验证pool中的数据。当一个设备被添加到pool中时ZFS在设备的最前面放两个Label最后面也放两个Label。下图显示四个Label的分布N表示设备的总大小L0、L1为前两个LabelL2、L3为后两个Label。 span 考虑到一般情况下设备的损坏都是一个连续的段所以要将Label放在两个不同的地方。 1.2.2 span 两阶段的事务性更新 Labelspan 的位置是在设备加入pool时就设定好了因此Label的更新并不能像ZFS对待其他数据那样采用Copy-On-Write技术也就是说对Label的更新是直接覆盖原有的数据。但是在写任何数据的过程中都有可能发生错误为了保证ZFS任何时候总是有一个合法的LabelLabel的更新过程被分为两个阶段。第一阶段更新偶数的LabelL0、L2如果在这一阶段中任何时刻发生了错误奇数LabelL1、L3仍然是合法的。在L0、L2更新结束之后第二阶段则是更新L1、L3。 1.3 vdev技术细节 vdev label的信息被分成了4部分8K的空闲空间Blank Space8K的boot header信息112K的name-value键值对以及128长度的1K大小的uberblock结构数组。下图显示了L0的扩展视图。 1.3.1 span 空闲空间 ZFS支持使用VTOCVolume 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下的设备。比如下图中的灰色圆内部的ABM1三个设备。 所有的键值对都使用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的保留空间。
