在前面一篇文章中，我们详细描述了disk header的结构以及其含义，其中从disk header中，我们发现了如下信息:

这里的kfdhdb.fstlocn表示Free Space Table (FST)，所以在asm剖析系列第2篇文章中，我将重点描述FST的结构。

不管是在10g还是在11g版本中，FST的信息都的存在固定的位置，如下：

从上面信息我们可以知道，FST信息存在第一个AU中，由于asm中，block编号都是从第0个开始，所以可以使用kfed
直接查看元数据信息，不过这里第0个block的数据并不是FST的信息，而是Partnership and Status Table (PST)信息。
顾名思义，PST，就是存放diskgroup中disk的关系以及disk状态灯信息，下面通过kfed来查看详细详细：

既然这里提到了PST，那么我们就首先来描述Partnership and Status Table (PST)的结构和含义。在前不久还遇到asm
添加disk时导致磁盘组无法mount，我通过模拟测试发现通过可以修改pst等信息将diskgroup成功mount，大家可以参考下：
asm 添加disk时，ctrl+C导致diskgroup无法mount

asm的pst信息通常都存在disk中的第一个AU中的前面几个block中，如下是这里的情况：

从上面信息可以看出，在前面2个block是存的pst元数据，而blk 2,3则是存放的pst数据。首先我们来分析pst的元数据.

正如我那篇文章所提到的那样，如果某个disk无法从diskgroup中去掉，进行重新添加时(10g至少是这样，11g可以force操作).
那么我们就可以通过去修改pst等元数据来完成，当然这个不建议随便操作，比较危险，除非你有十分的把握。即使操作也需要
先dd备份相关的au数据。提到pst，其实就必须要说一下asm的gmon进程，因为相关元数据的操作都是该进程来完成的，我这里
来strace跟踪下gmon的动作，同时我开另外一个sqlplus窗口进行drop disk操作，如下：

—-session 2

从上面的trace信息，我们可以看出，gmon进程在每次更新元数据时，每次写操作都是更新4096 byte，也就是一个block。最后的数字是offset。
简单换算一下，如下：

从上面的数据我们可以得到什么呢？ 由于第1(实际上是第0个au)个au只存255个block，那么从256开始到259就是在第2个au中(实际上是第1个au)，如下：

说明gmon进程操作了上述4个pst 数据块，其中2个元数据block，2个pst数据block。那么最后gmon进程操作的block 511又是什么呢？
通过分析trace，发现gmon进程每秒钟都会更新该block，如下：

我们来看下这个block 511是什么？

KFBTYP_HBEAT，很显然这是asm的disk心跳验证，oracle正是通过这个来判断某个disk是否属于某个磁盘组，以防止
其他磁盘组将该disk挂载。这里我猜测oracle是通过hash算法来计算hash值的，也就是上面的kfbh.check，通过
观察，正常情况下，该值基本上是几秒就会被更新，如下：

最后我们再回到前面的问题，Free Space Table (FST)是什么？其结构又是如何的？

上面的kfdfse.total，加起来就是disk /dev/sdd的大小1024m。同一个磁盘组里面的disk都存在fst信息，
而且信息基本上完全一致。如下：