ASM剖析(2)-pst/fst/allocator tabe
在前面一篇文章中，我们详细描述了disk header的结构以及其含义，其中从disk header中，我们发现了如下信息:
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=0| more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
......
kfdhdb.dsksize: 1024 ; 0x0c4: 0x00000400
kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
......
|
这里的kfdhdb.fstlocn表示Free Space Table (FST)，所以在asm剖析系列第2篇文章中，我将重点描述FST的结构。
不管是在10g还是在11g版本中，FST的信息都的存在固定的位置，如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=0 blkn=0 | grep fstlocn
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
[ora11g@11gR2test ~]$
|
从上面信息我们可以知道，FST信息存在第一个AU中，由于asm中，block编号都是从第0个开始，所以可以使用kfed
直接查看元数据信息，不过这里第0个block的数据并不是FST的信息，而是Partnership and Status Table (PST)信息。
顾名思义，PST，就是存放diskgroup中disk的关系以及disk状态灯信息，下面通过kfed来查看详细详细：
[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=0
kfbh.endian: 1 ; 0x000: 0x01 --1表示little，0表示big。
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 17 ; 0x002: KFBTYP_PST_META --表示PST元数据
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 841194965 ; 0x00c: 0x32239dd5
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi: 32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc
kfdpHdrB.time.lo: 2999004160 ; 0x004: USEC=0x0 MSEC=0x4b SECS=0x2c MINS=0x2c
kfdpHdrB.last: 3 ; 0x008: 0x00000003
kfdpHdrB.next: 3 ; 0x00c: 0x00000003
kfdpHdrB.copyCnt: 1 ; 0x010: 0x01
kfdpHdrB.ub1spare: 0 ; 0x011: 0x00
kfdpHdrB.ub2spare: 0 ; 0x012: 0x0000
kfdpHdrB.incarn: 0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]: 0 ; 0x018: 0x0000
kfdpHdrB.copy[1]: 0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]: 0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]: 0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]: 0 ; 0x020: 0x0000
kfdpHdrB.dtaSz: 4 ; 0x022: 0x0004
ub1[0]: 2 ; 0x024: 0x02
ub1[1]: 0 ; 0x025: 0x00
ub1[2]: 0 ; 0x026: 0x00
ub1[3]: 0 ; 0x027: 0x00
ub1[4]: 0 ; 0x028: 0x00
..........
ub1[4026]: 0 ; 0xfde: 0x00
ub1[4027]: 0 ; 0xfdf: 0x00
|
既然这里提到了PST，那么我们就首先来描述Partnership and Status Table (PST)的结构和含义。在前不久还遇到asm
添加disk时导致磁盘组无法mount，我通过模拟测试发现通过可以修改pst等信息将diskgroup成功mount，大家可以参考下：
asm 添加disk时，ctrl+C导致diskgroup无法mount
asm的pst信息通常都存在disk中的第一个AU中的前面几个block中，如下是这里的情况：
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=0 | grep type
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=1 | grep type
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=2 | grep type
kfbh.type: 18 ; 0x002: KFBTYP_PST_DTA
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=3 | grep type
kfbh.type: 18 ; 0x002: KFBTYP_PST_DTA
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=4 | grep type
kfbh.type: 13 ; 0x002: KFBTYP_PST_NONE
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=5 | grep type
kfbh.type:
|
从上面信息可以看出，在前面2个block是存的pst元数据，而blk 2,3则是存放的pst数据。首先我们来分析pst的元数据.
[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=0 |more
kfbh.endian: 1 ; 0x000: 0x01 ---0 表示big endian,1 表示little endian.
kfbh.hard: 130 ; 0x001: 0x82 ---这里是HARD magic number
kfbh.type: 17 ; 0x002: KFBTYP_PST_META ---这表示元数据block类型
kfbh.datfmt: 1 ; 0x003: 0x01 ---表示元数据block格式
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100 ---表示block位置
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 841194965 ; 0x00c: 0x32239dd5 --主要是做校验用的，check一致性
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi: 32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc --最后一次pst元数据的更新时间，这是高位
kfdpHdrB.time.lo: 2999004160 ; 0x004: USEC=0x0 MSEC=0x4b SECS=0x2c MINS=0x2c --最后一次pst元数据的更新时间，这是地位
kfdpHdrB.last: 3 ; 0x008: 0x00000003 ---最新的disk版本号
kfdpHdrB.next: 3 ; 0x00c: 0x00000003 ---下一个disk版本号
kfdpHdrB.copyCnt: 1 ; 0x010: 0x01 ---表示PST元数据的备份信息，如果是1表示磁盘组是external冗余。如果是3那么则是normal。
kfdpHdrB.ub1spare: 0 ; 0x011: 0x00
kfdpHdrB.ub2spare: 0 ; 0x012: 0x0000
kfdpHdrB.incarn: 0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]: 0 ; 0x018: 0x0000
kfdpHdrB.copy[1]: 0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]: 0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]: 0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]: 0 ; 0x020: 0x0000
kfdpHdrB.dtaSz: 4 ; 0x022: 0x0004 ---表示pst元数据中，diskgroup所包含的disk个数
ub1[0]: 2 ; 0x024: 0x02
........
[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=1 |more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 257 ; 0x004: T=0 NUMB=0x101
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 847094230 ; 0x00c: 0x327da1d6
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi: 32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc
kfdpHdrB.time.lo: 2996768768 ; 0x004: USEC=0x0 MSEC=0x3c4 SECS=0x29 MINS=0x2c
kfdpHdrB.last: 2 ; 0x008: 0x00000002
kfdpHdrB.next: 3 ; 0x00c: 0x00000003
kfdpHdrB.copyCnt: 1 ; 0x010: 0x01
kfdpHdrB.ub1spare: 0 ; 0x011: 0x00
kfdpHdrB.ub2spare: 0 ; 0x012: 0x0000
kfdpHdrB.incarn: 0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]: 0 ; 0x018: 0x0000
kfdpHdrB.copy[1]: 0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]: 0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]: 0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]: 0 ; 0x020: 0x0000
kfdpHdrB.dtaSz: 4 ; 0x022: 0x0004
ub1[0]: 1 ; 0x024: 0x01
ub1[1]: 0 ; 0x025: 0x00
..........
|
正如我那篇文章所提到的那样，如果某个disk无法从diskgroup中去掉，进行重新添加时(10g至少是这样，11g可以force操作).
那么我们就可以通过去修改pst等元数据来完成，当然这个不建议随便操作，比较危险，除非你有十分的把握。即使操作也需要
先dd备份相关的au数据。提到pst，其实就必须要说一下asm的gmon进程，因为相关元数据的操作都是该进程来完成的，我这里
来strace跟踪下gmon的动作，同时我开另外一个sqlplus窗口进行drop disk操作，如下：
---session 1 SQL>SELECT2 NVL(a.name,'[CANDIDATE]') disk_group_name 3, b.path disk_file_path 4, b.name disk_file_name 5, b.failgroup disk_file_fail_group 6, b.total_mb total_mb 7,(b.total_mb - b.free_mb) used_mb 8, ROUND((1-(b.free_mb / b.total_mb))*100,2) pct_used 9FROM10 v$asm_diskgroup a RIGHTOUTERJOIN v$asm_disk b USING(group_number)11ORDERBY12 a.name 13/
Path File Name Fail GROUP File SIZE(MB) Used SIZE(MB) Pct. Used ----------------- -------------------- -------------------- -------------- -------------- ---------/dev/sdb DATA1_0002 DATA1_0002 1,024 2.20 /dev/sdc DATA1_0001 DATA1_0001 1,024 50349.12/dev/sdd DATA1_0000 DATA1_0000 1,024 50449.22/dev/sde DATA1_0003 DATA1_0003 1,024 2.20 -------------- --------------4,096 1,011
-------------- --------------4,096 1,011
SQL>ALTER diskgroup data1 DROP disk DATA1_0003;
Diskgroup altered.
SQL>
|
—-session 2
trace信息如下：
[oracle@10gasm tmp]$ cat 3.log |grep write
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200i]\334\\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000069 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\2740\233\202\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000154 write(2, "*** 2013-01-07 06:43:38.072", 27) = 27
30006 0.000091 write(2, "\n", 1) = 1
30006 0.000059 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006 0.000105 write(2, "\n", 1) = 1
30006 0.000056 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\322\235#2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006 0.000058 pwrite64(19, "\1\202\22\1\2\1\0\0\0\0\0\200\3\203\22\201\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1056768) = 4096
30006 0.000081 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\346\357\203.\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006 0.000037 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006 0.000046 write(2, "\n", 1) = 1
30006 0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\17@f*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200s\216\2T\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\311TQK\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\252gB\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000028 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\221\310\n`\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000046 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\301[~G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000047 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\212j\202\365\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200i\304\307\31\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000029 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200$V\212{\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000036 write(2, "*** 2013-01-07 06:44:11.939", 27) = 27
30006 0.000055 write(2, "\n", 1) = 1
30006 0.000041 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006 0.000049 write(2, "\n", 1) = 1
30006 0.000024 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347\357\203.\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006 0.000040 pwrite64(19, "\1\202\22\1\3\1\0\0\0\0\0\200\2\203\22\201\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1060864) = 4096
30006 0.000037 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\344s\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006 0.000040 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006 0.000049 write(2, "\n", 1) = 1
30006 0.000028 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006 0.000034 write(2, "\n", 1) = 1
30006 0.000039 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347s\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006 0.000025 pwrite64(19, "\1\202\22\1\2\1\0\0\0\0\0\200\3\203\22\203\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1056768) = 4096
30006 0.000024 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\346\23#0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006 0.000039 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006 0.000053 write(2, "\n", 1) = 1
30006 0.000036 write(2, "PST verChk 3: ack, id=2593589894"..., 56) = 56
30006 0.000049 write(2, "\n", 1) = 1
30006 0.000024 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006 0.000032 write(2, "\n", 1) = 1
30006 0.000028 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347\23$0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006 0.000023 pwrite64(19, "\1\202\22\1\3\1\0\0\0\0\0\200\2\203\22\206\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1060864) = 4096
30006 0.000024 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\344+$0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006 0.000024 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006 0.000031 write(2, "\n", 1) = 1
30006 0.000028 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\2007Ip\246\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000033 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200Au\236\35\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000029 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200h\3174V\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000031 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\215]\246\214\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000023 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\324*\30E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200Fy]\313\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\321{\275\357\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\261WC\274\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\36@\335k\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
[oracle@10gasm tmp]$
上面的file 2是gmon进程产生的trace文件，而file 19正是/dev/sdd，如下：
[oracle@10gasm fd]$ ls -ltr
total 0
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 9 -> /home/oracle/oracle/product/10.2.0/dbs/hc_+ASM.dat
l-wx------ 1 oracle oinstall 64 Jan 7 06:47 8 -> /home/oracle/admin/+ASM/bdump/alert_+ASM.log
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 7 -> /home/oracle/oracle/product/10.2.0/dbs/lkinst+ASM (deleted)
l-wx------ 1 oracle oinstall 64 Jan 7 06:47 6 -> /home/oracle/admin/+ASM/bdump/alert_+ASM.log
l-wx------ 1 oracle oinstall 64 Jan 7 06:47 5 -> /home/oracle/admin/+ASM/udump/+asm_ora_29975.trc
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 4 -> /dev/null
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 3 -> /dev/null
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 20 -> /dev/sdc
l-wx------ 1 oracle oinstall 64 Jan 7 06:47 2 -> /home/oracle/admin/+ASM/bdump/+asm_gmon_30006.trc
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 19 -> /dev/sdd
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 18 -> socket:[253917]
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 17 -> socket:[253916]
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 16 -> /home/oracle/oracle/product/10.2.0/cdata/localhost/local.ocr
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 15 -> /home/oracle/oracle/product/10.2.0/srvm/mesg/procus.msb
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 14 -> /home/oracle/oracle/product/10.2.0/dbs/hc_+ASM.dat
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 13 -> /home/oracle/oracle/product/10.2.0/rdbms/mesg/oraus.msb
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 12 -> /dev/zero
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 11 -> /dev/zero
lrwx------ 1 oracle oinstall 64 Jan 7 06:47 10 -> /home/oracle/oracle/product/10.2.0/rdbms/audit/ora_29975.aud
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 1 -> /dev/null
lr-x------ 1 oracle oinstall 64 Jan 7 06:47 0 -> /dev/null
|
从上面的trace信息，我们可以看出，gmon进程在每次更新元数据时，每次写操作都是更新4096 byte，也就是一个block。最后的数字是offset。
简单换算一下，如下：
SQL>SELECT1048576/4096FROM dual;
1048576/4096------------256 SQL>SELECT1052672/4096FROM dual;
1052672/4096------------257 SQL>SELECT1056768/4096FROM dual;
1056768/4096------------258 SQL>SELECT1060864/4096FROM dual;
1060864/4096------------259 SQL>SELECT2093056/4096FROM dual;
2093056/4096------------511
|
从上面的数据我们可以得到什么呢？ 由于第1(实际上是第0个au)个au只存255个block，那么从256开始到259就是在第2个au中(实际上是第1个au)，如下：
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=256|grep type
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=257|grep type
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=258|grep type
kfbh.type: 18 ; 0x002: KFBTYP_PST_DTA
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=259|grep type
kfbh.type: 18 ; 0x002: KFBTYP_PST_DTA
[oracle@10gasm ~]$
|
说明gmon进程操作了上述4个pst 数据块，其中2个元数据block，2个pst数据block。那么最后gmon进程操作的block 511又是什么呢？
通过分析trace，发现gmon进程每秒钟都会更新该block，如下：
30006 0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\17@f*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.001413 times(NULL) = 445917247
30006 0.000071 gettimeofday({1357569818, 778684}, NULL) = 0
..........
30006 0.000031 gettimeofday({1357569822, 909002}, NULL) = 0
30006 0.000070 times(NULL) = 445917547
30006 0.000032 poll([{fd=17, events=POLLIN|POLLRDNORM}, {fd=17, events=0}, {fd=18, events=POLLIN|POLLRDNORM}, {fd=18, events=0}], 4, 0) = 0 (Timeout)
30006 0.000038 times(NULL) = 445917547
30006 0.000020 times(NULL) = 445917547
30006 0.000028 gettimeofday({1357569822, 909190}, NULL) = 0
30006 0.000024 gettimeofday({1357569822, 909214}, NULL) = 0
30006 0.000038 gettimeofday({1357569822, 909253}, NULL) = 0
30006 0.000046 times(NULL) = 445917547
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200s\216\2T\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.005612 times(NULL) = 445917548
30006 0.000057 gettimeofday({1357569822, 914994}, NULL) = 0
..........
30006 0.000027 semtimedop(3506176, 0xbf9ccb68, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
30006 4.024697 gettimeofday({1357569826, 939952}, NULL) = 0
30006 0.000054 gettimeofday({1357569826, 939985}, NULL) = 0
..........
30006 0.000084 gettimeofday({1357569826, 940574}, NULL) = 0
30006 0.000053 times(NULL) = 445917848
30006 0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\311TQK\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.141790 times(NULL) = 445917858
30006 0.000054 gettimeofday({1357569827, 82494}, NULL) = 0
.........
30006 0.000028 gettimeofday({1357569827, 82694}, NULL) = 0
30006 0.000030 semtimedop(3506176, 0xbf9ccb68, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
30006 4.067061 gettimeofday({1357569831, 149787}, NULL) = 0
30006 0.000032 gettimeofday({1357569831, 149852}, NULL) = 0
........
30006 0.000038 gettimeofday({1357569831, 150224}, NULL) = 0
30006 0.000031 gettimeofday({1357569831, 150254}, NULL) = 0
30006 0.000026 times(NULL) = 445918159
30006 0.000025 poll([{fd=17, events=POLLIN|POLLRDNORM}, {fd=17, events=0}, {fd=18, events=POLLIN|POLLRDNORM}, {fd=18, events=0}], 4, 0) = 0 (Timeout)
30006 0.000038 times(NULL) = 445918159
........
30006 0.000040 gettimeofday({1357569831, 150460}, NULL) = 0
30006 0.000052 times(NULL) = 445918159
30006 0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\252gB\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006 0.038081 times(NULL) = 445918161
30006 0.000107 gettimeofday({1357569831, 188731}, NULL) = 0
|
我们来看下这个block 511是什么？
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 19 ; 0x002: KFBTYP_HBEAT
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 511 ; 0x004: T=0 NUMB=0x1ff
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 1801389837 ; 0x00c: 0x6b5f070d
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdpHbeatB.instance: 0 ; 0x000: 0x00000000
kfdpHbeatB.ts.hi: 32982247 ; 0x004: HOUR=0x7 DAYS=0x7 MNTH=0x1 YEAR=0x7dd
kfdpHbeatB.ts.lo: 1823758336 ; 0x008: USEC=0x0 MSEC=0x116 SECS=0xb MINS=0x1b
kfdpHbeatB.rnd[0]: 4243380219 ; 0x00c: 0xfcecd7fb
kfdpHbeatB.rnd[1]: 4223846872 ; 0x010: 0xfbc2c9d8
kfdpHbeatB.rnd[2]: 544685178 ; 0x014: 0x20773c7a
kfdpHbeatB.rnd[3]: 2690038349 ; 0x018: 0xa056ba4d
|
KFBTYP_HBEAT，很显然这是asm的disk心跳验证，oracle正是通过这个来判断某个disk是否属于某个磁盘组，以防止
其他磁盘组将该disk挂载。这里我猜测oracle是通过hash算法来计算hash值的，也就是上面的kfbh.check，通过
观察，正常情况下，该值基本上是几秒就会被更新，如下：
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check: 1696975138 ; 0x00c: 0x6525c922
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check: 238939432 ; 0x00c: 0x0e3ded28
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check: 931877671 ; 0x00c: 0x378b5327
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check: 625709379 ; 0x00c: 0x254b9143
|
最后我们再回到前面的问题，Free Space Table (FST)是什么？其结构又是如何的？
[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=0 blkn=0 | grep fstlocn
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
[ora11g@11gR2test ~]$
前面我们用kfed读取，看到fst的第1个block应该是1，而位置就是第1个AU，如下：
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2147519081 ; 0x00c: 0x80008a69
kfbh.fcn.base: 2071 ; 0x010: 0x00000817
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdfsb.aunum: 0 ; 0x000: 0x00000000
kfdfsb.max: 254 ; 0x004: 0x00fe
kfdfsb.cnt: 3 ; 0x006: 0x0003
kfdfse[0].total: 448 ; 0x008: 0x01c0
kfdfse[0].free: 1 ; 0x00a: 0x01
kfdfse[0].frag: 1 ; 0x00b: 0x01
kfdfse[1].total: 448 ; 0x00c: 0x01c0
kfdfse[1].free: 1 ; 0x00e: 0x01
kfdfse[1].frag: 1 ; 0x00f: 0x01
kfdfse[2].total: 128 ; 0x010: 0x0080
kfdfse[2].free: 1 ; 0x012: 0x01
kfdfse[2].frag: 1 ; 0x013: 0x01
kfdfse[3].total: 0 ; 0x014: 0x0000
kfdfse[3].free: 0 ; 0x016: 0x00
........
|
上面的kfdfse.total，加起来就是disk /dev/sdd的大小1024m。同一个磁盘组里面的disk都存在fst信息，
而且信息基本上完全一致。如下：
[oracle@10gasm ~]$ kfed read /dev/sdc aun=0 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj: 2147483649 ; 0x008: TYPE=0x8 NUMB=0x1
kfbh.check: 2147519071 ; 0x00c: 0x80008a5f
kfbh.fcn.base: 2080 ; 0x010: 0x00000820
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdfsb.aunum: 0 ; 0x000: 0x00000000
kfdfsb.max: 254 ; 0x004: 0x00fe
kfdfsb.cnt: 3 ; 0x006: 0x0003
kfdfse[0].total: 448 ; 0x008: 0x01c0
kfdfse[0].free: 1 ; 0x00a: 0x01
kfdfse[0].frag: 1 ; 0x00b: 0x01
kfdfse[1].total: 448 ; 0x00c: 0x01c0
kfdfse[1].free: 1 ; 0x00e: 0x01
kfdfse[1].frag: 1 ; 0x00f: 0x01
kfdfse[2].total: 128 ; 0x010: 0x0080
kfdfse[2].free: 1 ; 0x012: 0x01
kfdfse[2].frag: 1 ; 0x013: 0x01
kfdfse[3].total: 0 ; 0x014: 0x0000
kfdfse[3].free: 0 ; 0x016: 0x00
kfdfse[3].frag: 0 ; 0x017: 0x00
kfdfse[4].total: 0 ; 0x018: 0x0000
........
[oracle@10gasm ~]$ kfed read /dev/sdb aun=0 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj: 2147483650 ; 0x008: TYPE=0x8 NUMB=0x2
kfbh.check: 2147517052 ; 0x00c: 0x8000827c
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdfsb.aunum: 0 ; 0x000: 0x00000000 ---对应的au编号
kfdfsb.max: 254 ; 0x004: 0x00fe
kfdfsb.cnt: 3 ; 0x006: 0x0003 ---当前disk包含的fst kfdfse条目数。
kfdfse[0].total: 448 ; 0x008: 0x01c0
kfdfse[0].free: 1 ; 0x00a: 0x01
kfdfse[0].frag: 1 ; 0x00b: 0x01
kfdfse[1].total: 448 ; 0x00c: 0x01c0
kfdfse[1].free: 1 ; 0x00e: 0x01
kfdfse[1].frag: 1 ; 0x00f: 0x01
kfdfse[2].total: 128 ; 0x010: 0x0080
kfdfse[2].free: 1 ; 0x012: 0x01
kfdfse[2].frag: 1 ; 0x013: 0x01
kfdfse[3].total: 0 ; 0x014: 0x0000
kfdfse[3].free: 0 ; 0x016: 0x00
除了标注信息外，其他信息，没有什么实际意义，不过多描述。
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=2|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2 ; 0x004: T=0 NUMB=0x2
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 980649727 ; 0x00c: 0x3a7386ff
kfbh.fcn.base: 2465 ; 0x010: 0x000009a1
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb.aunum: 0 ; 0x000: 0x00000000
kfdatb.shrink: 448 ; 0x004: 0x01c0
kfdatb.ub2pad: 46872 ; 0x006: 0xb718
kfdatb.auinfo[0].link.next: 3608 ; 0x008: 0x0e18
kfdatb.auinfo[0].link.prev: 256 ; 0x00a: 0x0100
kfdatb.auinfo[0].free: 149 ; 0x00c: 0x0095
kfdatb.auinfo[0].total: 448 ; 0x00e: 0x01c0
kfdatb.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 8388608 ; 0x02c: V=1 I=0 FNUM=0x0
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
kfdate[1].allo.hi: 8388608 ; 0x034: V=1 I=0 FNUM=0x0
kfdate[2].allo.lo: 0 ; 0x038: XNUM=0x0
kfdate[2].allo.hi: 8388609 ; 0x03c: V=1 I=0 FNUM=0x1
kfdate[3].allo.lo: 1 ; 0x040: XNUM=0x1
kfdate[3].allo.hi: 8388611 ; 0x044: V=1 I=0 FNUM=0x3
kfdate[4].allo.lo: 3 ; 0x048: XNUM=0x3
kfdate[4].allo.hi: 8388611 ; 0x04c: V=1 I=0 FNUM=0x3
kfdate[5].allo.lo: 7 ; 0x050: XNUM=0x7
kfdate[5].allo.hi: 8388611 ; 0x054: V=1 I=0 FNUM=0x3
kfdate[6].free.lo.next: 256 ; 0x058: 0x0100
kfdate[6].free.lo.prev: 120 ; 0x05a: 0x0078
kfdate[6].free.hi: 0 ; 0x05c: V=0 ASZM=0x0
kfdate[7].allo.lo: 11 ; 0x060: XNUM=0xb
kfdate[7].allo.hi: 8388611 ; 0x064: V=1 I=0 FNUM=0x3
kfdate[8].allo.lo: 13 ; 0x068: XNUM=0xd
kfdate[8].allo.hi: 8388611 ; 0x06c: V=1 I=0 FNUM=0x3
kfdate[9].allo.lo: 15 ; 0x070: XNUM=0xf
kfdate[9].allo.hi: 8388611 ; 0x074: V=1 I=0 FNUM=0x3
kfdate[10].free.lo.next: 88 ; 0x078: 0x0058
kfdate[10].free.lo.prev: 136 ; 0x07a: 0x0088
kfdate[10].free.hi: 0 ; 0x07c: V=0 ASZM=0x0
kfdate[11].allo.lo: 19 ; 0x080: XNUM=0x13
kfdate[11].allo.hi: 8388611 ; 0x084: V=1 I=0 FNUM=0x3
kfdate[12].free.lo.next: 120 ; 0x088: 0x0078
kfdate[12].free.lo.prev: 152 ; 0x08a: 0x0098
kfdate[12].free.hi: 0 ; 0x08c: V=0 ASZM=0x0
kfdate[13].allo.lo: 21 ; 0x090: XNUM=0x15
kfdate[13].allo.hi: 8388611 ; 0x094: V=1 I=0 FNUM=0x3
kfdate[14].free.lo.next: 136 ; 0x098: 0x0088
kfdate[14].free.lo.prev: 184 ; 0x09a: 0x00b8
kfdate[14].free.hi: 0 ; 0x09c: V=0 ASZM=0x0
kfdate[15].allo.lo: 25 ; 0x0a0: XNUM=0x19
kfdate[15].allo.hi: 8388611 ; 0x0a4: V=1 I=0 FNUM=0x3
kfdate[16].allo.lo: 29 ; 0x0a8: XNUM=0x1d
kfdate[16].allo.hi: 8388611 ; 0x0ac: V=1 I=0 FNUM=0x3
kfdate[17].allo.lo: 30 ; 0x0b0: XNUM=0x1e
kfdate[17].allo.hi: 8388611 ; 0x0b4: V=1 I=0 FNUM=0x3
kfdate[18].free.lo.next: 152 ; 0x0b8: 0x0098
kfdate[18].free.lo.prev: 192 ; 0x0ba: 0x00c0
kfdate[18].free.hi: 0 ; 0x0bc: V=0 ASZM=0x0
kfdate[19].free.lo.next: 184 ; 0x0c0: 0x00b8
kfdate[19].free.lo.prev: 208 ; 0x0c2: 0x00d0
kfdate[19].free.hi: 0 ; 0x0c4: V=0 ASZM=0x0
kfdate[20].allo.lo: 33 ; 0x0c8: XNUM=0x21
kfdate[20].allo.hi: 8388611 ; 0x0cc: V=1 I=0 FNUM=0x3
kfdate[21].free.lo.next: 192 ; 0x0d0: 0x00c0
kfdate[21].free.lo.prev: 240 ; 0x0d2: 0x00f0
kfdate[21].free.hi: 0 ; 0x0d4: V=0 ASZM=0x0
kfdate[22].allo.lo: 36 ; 0x0d8: XNUM=0x24
..........
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=3|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 3 ; 0x004: T=0 NUMB=0x3
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 941327592 ; 0x00c: 0x381b84e8
kfbh.fcn.base: 2516 ; 0x010: 0x000009d4
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb.aunum: 448 ; 0x000: 0x000001c0
kfdatb.shrink: 448 ; 0x004: 0x01c0
kfdatb.ub2pad: 46872 ; 0x006: 0xb718
kfdatb.auinfo[0].link.next: 424 ; 0x008: 0x01a8
kfdatb.auinfo[0].link.prev: 3616 ; 0x00a: 0x0e20
kfdatb.auinfo[0].free: 411 ; 0x00c: 0x019b
kfdatb.auinfo[0].total: 448 ; 0x00e: 0x01c0
kfdatb.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].allo.lo: 33 ; 0x028: XNUM=0x21
kfdate[0].allo.hi: 8388870 ; 0x02c: V=1 I=0 FNUM=0x106
kfdate[1].free.lo.next: 480 ; 0x030: 0x01e0
kfdate[1].free.lo.prev: 72 ; 0x032: 0x0048
kfdate[1].free.hi: 0 ; 0x034: V=0 ASZM=0x0
kfdate[2].allo.lo: 37 ; 0x038: XNUM=0x25
kfdate[2].allo.hi: 8388870 ; 0x03c: V=1 I=0 FNUM=0x106
kfdate[3].allo.lo: 39 ; 0x040: XNUM=0x27
kfdate[3].allo.hi: 8388870 ; 0x044: V=1 I=0 FNUM=0x106
kfdate[4].free.lo.next: 48 ; 0x048: 0x0030
kfdate[4].free.lo.prev: 96 ; 0x04a: 0x0060
kfdate[4].free.hi: 0 ; 0x04c: V=0 ASZM=0x0
kfdate[5].allo.lo: 43 ; 0x050: XNUM=0x2b
kfdate[5].allo.hi: 8388870 ; 0x054: V=1 I=0 FNUM=0x106
kfdate[6].allo.lo: 45 ; 0x058: XNUM=0x2d
kfdate[6].allo.hi: 8388870 ; 0x05c: V=1 I=0 FNUM=0x106
kfdate[7].free.lo.next: 72 ; 0x060: 0x0048
kfdate[7].free.lo.prev: 120 ; 0x062: 0x0078
kfdate[7].free.hi: 0 ; 0x064: V=0 ASZM=0x0
kfdate[8].allo.lo: 49 ; 0x068: XNUM=0x31
kfdate[8].allo.hi: 8388870 ; 0x06c: V=1 I=0 FNUM=0x106
kfdate[9].allo.lo: 51 ; 0x070: XNUM=0x33
kfdate[9].allo.hi: 8388870 ; 0x074: V=1 I=0 FNUM=0x106
kfdate[10].free.lo.next: 96 ; 0x078: 0x0060
kfdate[10].free.lo.prev: 136 ; 0x07a: 0x0088
kfdate[10].free.hi: 0 ; 0x07c: V=0 ASZM=0x0
kfdate[11].allo.lo: 55 ; 0x080: XNUM=0x37
kfdate[11].allo.hi: 8388870 ; 0x084: V=1 I=0 FNUM=0x106
kfdate[12].free.lo.next: 120 ; 0x088: 0x0078
kfdate[12].free.lo.prev: 160 ; 0x08a: 0x00a0
........
|
au 0上，从block 1开始到255，都是 ASM allocator table信息，你可以想象为这些au的分配关系都被串成一个
链表，每个链表上的一个点都是一个指针，对应做一个AU编号。
最后奉上一个图，清晰的描述了asm元数据的关系，一目了然。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29953799/viewspace-1423416/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
ASM剖析(1)-disk header
请登录后发表评论
登录
全部评论
