SAN最终给客户提供的是基于块设备的存储,客户实际分区格式化用到的文件系统的类型决定了上层的data/ meta data的组织形式,但是对提供块存储设备的系统而言,上层的data/medta data都是它的data,都需要根据上层传递进来的flag (O_DIREC/O_SYNC/O_DSYNC)到达io 队列或者磁盘。而提供块存储的 文件系统中的其他数据结构都是meta data。

因此,zfs中的meta data包括:

  • 首尾的四个label

ZFS的元数据_第1张图片

其中每个Label存储了跟整个系统池相关的全局信息,结构如下:
ZFS的元数据_第2张图片

  • uber block、name value pair
    super block 如何定位到具体的磁盘偏移super block中是索引数据的入口? 下图红线部分指出了相关数据结构之间的关联:
    ZFS的元数据_第3张图片

  • 基于叶子节点的vtree
    在上面112KB的Label 区间,有一个叫做vdev tree 的name-value pairs,内容如下:

ZFS的元数据_第4张图片
两个或多个vdev可以构成不同类型和级别的vtree,比如RAID1/2/3//5/10等。以下面的截图为例来说明一个基于两个叶子节点的mirror 的name-value pairs:

上面中的ubber-block框图可以由来解释基于块的zfs on-disk静态数据的layout结构,那么这些块block又是如何管理的呢?实际是由zfs DMU统一管理文件系统操作的所有的对象,比如dnode/directory/zvol/intent log 都抽象成一个object。 由SPA层根据object/object set的需求一块块申请和分配、释放的.