SAN最终给客户提供的是基于块设备的存储，客户实际分区格式化用到的文件系统的类型决定了上层的data/ meta data的组织形式，但是对提供块存储设备的系统而言，上层的data/medta data都是它的data，都需要根据上层传递进来的flag (O_DIREC/O_SYNC/O_DSYNC)到达io 队列或者磁盘。而提供块存储的 文件系统中的其他数据结构都是meta data。
因此，zfs中的meta data包括：
- 首尾的四个label
其中每个Label存储了跟整个系统池相关的全局信息，结构如下：
-
uber block、name value pair
super block 如何定位到具体的磁盘偏移super block中是索引数据的入口? 下图红线部分指出了相关数据结构之间的关联：
- 基于叶子节点的vtree
在上面112KB的Label 区间，有一个叫做vdev tree 的name-value pairs，内容如下：
两个或多个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的需求一块块申请和分配、释放的.