Oracle ASM Disk Directory
ASM的2号文件就是ASM磁盘目录，它用来跟踪磁盘组中的所有磁盘。当磁盘组是一个独立的存储单元时，每个磁盘组有属于它自己的ASM磁盘目录。ASM中每一个磁盘组都是自解释的，磁盘组之间没有任何的信息上依赖。
对ASM来说，磁盘目录只是一个普通的ASM文件。在ASM的文件目录中也会有它的条目,当磁盘组应用冗余策略时，磁盘目录也会生成镜像副本，并且也会像其他文件一样根据实际需要而增长。
每个磁盘目录条目维护以下内容:
.磁盘号
.磁盘的状态
.磁盘的名称(可能与操作系统所显示的磁盘名不一样)
.所在的Failgroup名称
.创建的时间戳
.故障的时间戳
.故障时间(自失败时间戳截止目前的时间)
.resize目标值
.磁盘修复时间
.Zone的信息
V$ASM_DISK视图
磁盘目录中所维护的大部分信息都可以通过查询v$asm_disk视图来获得。对于被发现的每个磁盘在视图中都有一条记录来表示，包括那些不属于任何磁盘组的磁盘。当每次查询v$asm_disk视图时，ASM就会执行磁盘发现操作，因此对这个视图执行查询的是有代价的。
下面的例子显示了在ASM实例中查询V$ASM_DISK视图的输出
SQL> select group_number, disk_number, state, name, mount_status from v$asm_disk order by 1,2;
GROUP_NUMBER DISK_NUMBER STATE NAME MOUNT_STATUS
------------ ----------- ------------------------------ ------------------------------ --------------
0 0 NORMAL CLOSED
0 1 NORMAL CLOSED
0 2 NORMAL CLOSED
0 3 NORMAL CLOSED
0 4 NORMAL CLOSED
0 5 NORMAL CLOSED
1 0 NORMAL ARCHDG_0000 CACHED
1 1 NORMAL ARCHDG_0001 CACHED
2 0 NORMAL CRSDG_0000 CACHED
2 1 NORMAL CRSDG_0001 CACHED
3 0 NORMAL DATADG_0001 CACHED
3 1 NORMAL DATADG_0003 CACHED
3 2 NORMAL DATADG_0002 CACHED
3 3 NORMAL DATADG_0000 CACHED
14 rows selected.
获得了所有ASM识别到的磁盘，包括了哪些不是当前正mount磁盘组(GROUP_NUMBER=0)的磁盘。
V$ASM_DISK_STAT视图
视图V$ASM_DISK_STAT展示了跟V$ASM_DISK相同的信息，不过查询V$ASM_DISK_STAT并不会执行发现所有磁盘的操作。它的信息来自于ASM实例的SGA区，查询V$ASM_DISK_STAT的代价不大，因为并不进行发现磁盘的操作，但是这个查询的结果可能并不能实时反应系统磁盘的现状。并且V$ASM_DISK_STAT中的信息只能反映出当前挂载磁盘组的磁盘信息，而不仅仅是不能反映出系统新加入的盘的信息。
下面的查询显示了在ASM实例中查询V$ASM_DISK_STAT视图的输出
SQL> select group_number, disk_number, state, name, mount_status from v$asm_disk_stat order by 1,2;
GROUP_NUMBER DISK_NUMBER STATE NAME MOUNT_STATUS
------------ ----------- ------------------------------ ------------------------------ --------------
1 0 NORMAL ARCHDG_0000 CACHED
1 1 NORMAL ARCHDG_0001 CACHED
2 0 NORMAL CRSDG_0000 CACHED
2 1 NORMAL CRSDG_0001 CACHED
3 0 NORMAL DATADG_0001 CACHED
3 1 NORMAL DATADG_0003 CACHED
3 2 NORMAL DATADG_0002 CACHED
3 3 NORMAL DATADG_0000 CACHED
8 rows selected.
只看到了mount的磁盘组上的磁盘
磁盘目录存储位置
可通过在ASM实例中查询固定表X$KFFXP来找到属于ASM 2号文件磁盘目录的AU分布情况。并且通过关联v$asm_disk_stat视图可以获得磁盘名，下面来查询磁盘组3(datadg)的磁盘目录AU分布情况。
SQL> select group_number,disk_number,name,path,state from v$asm_disk where group_number=3 order by 1,2;
GROUP_NUMBER DISK_NUMBER NAME PATH STATE
------------ ----------- ------------------------------ ------------------------------ ------------------------------
3 0 DATADG_0001 /dev/raw/raw11 NORMAL
3 1 DATADG_0003 /dev/raw/raw4 NORMAL
3 2 DATADG_0002 /dev/raw/raw3 NORMAL
3 3 DATADG_0000 /dev/raw/raw10 NORMAL
SQL> select x.xnum_kffxp "virtual extent",pxn_kffxp "physical extent",x.au_kffxp "au",x.disk_kffxp "disk #",d.name "disk name"
2 from x$kffxp x, v$asm_disk_stat d
3 where x.group_kffxp=d.group_number
4 and x.disk_kffxp=d.disk_number
5 and x.group_kffxp=3
6 and x.number_kffxp=2
7 order by 1, 2;
virtual extent physical extent au disk # disk name
-------------- --------------- ---------- ---------- ------------------------------------------------------------
0 0 3 2 DATADG_0002
0 1 3 0 DATADG_0001
0 2 3 1 DATADG_0003
上面的结果可以看出ASM的磁盘目录有三份镜像，当前磁盘目录的大小是3个物理extent（本例中也就是3个AU），再次强调，即使在一个normal冗余的磁盘组中，ASM的磁盘目录也有三份镜像。让我们使用kfed工具查看下磁盘目录的具体内容，由于数据在3个AU中是一样的，我们只需要查看第一个AU的内容就可以了，这里是DATADG_0001(/dev/raw/raw11)的AU 3:
[grid@jyrac1 ~]$ kfed read /dev/raw/raw11 aun=3 | more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 6 ; 0x002: KFBTYP_DISKDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 2 ; 0x008: file=2 kfbh.check: 17204021 ; 0x00c: 0x01068335 kfbh.fcn.base: 311 ; 0x010: 0x00000137 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 0 ; 0x014: 0x00000000 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 0 ; 0x01c: 0x00000000 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfddde[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfddde[0].entry.hash: 0 ; 0x028: 0x00000000 kfddde[0].entry.refer.number:4294967295 ; 0x02c: 0xffffffff kfddde[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfddde[0].dsknum: 0 ; 0x034: 0x0000 --diskgroup中，该disk的disk编号，从0开始排序，该值为0，说明该disk是这个磁盘组中的第一个disk kfddde[0].state: 2 ; 0x036: KFDSTA_NORMAL--disk状态。其中2表示normal。在asm中，该值对应v$asm_disk.state，主要有如下几种值： UNKNOWN ---disk不被diskgroup所识别，通常是diskgroup没有mount。 NORMAL ---disk目前处于online状态，操作正常。 ADDING ---表示disk正在被加入到diskgroup当中，其中add disk过程涉及到一系列的操作，包括更新pst,fst,disk dir以及reblance等各项操作。 DROPPING ---表示disk正在被从某个diskgroup中删除，该操作可以认为是adding的相反过程 HUNG ---该状态表示在drop disk的过程中，由于diskgroup 空间不足而不能完成reblance操作而导致disk处于hung状态。 FORCING ---该状态表示disk已经从diskgroup中移除，但是其disk上的数据尚未被卸载，很可能是强制drop。 DROPPED ---表示disk已经从diskgroup中删除且完成了一系列的相关操作。 #define KFDSTA_INVALID ((kfdsta)0) /* Illegal value */ #define KFDSTA_UNKNOWN ((kfdsta)1) /* ASM disk state not known */ #define KFDSTA_NORMAL ((kfdsta)2) /* Happy disk */ #define KFDSTA_UNUSED ((kfdsta)3) /* Unused State - Open */ #define KFDSTA_DROPPING ((kfdsta)4) /* Disk being dropped from group */ #define KFDSTA_HUNG ((kfdsta)5) /* Disk drop operation hung */ #define KFDSTA_FORCING ((kfdsta)6) /* Disk beinng drop forced */ #define KFDSTA_DROPPED ((kfdsta)7) /* Disk no longer part of group */ #define KFDSTA_ADDING ((kfdsta)8) /* Disk being globally validated */ kfddde[0].ddchgfl: 132 ; 0x037: 0x84 kfddde[0].dskname: DATADG_0001 ; 0x038: length=11 --磁盘名称，这是asm中定义的diskname. kfddde[0].fgname: DATADG_0001 ; 0x058: length=11 --这表示failgroup diskname kfddde[0].crestmp.hi: 33042831 ; 0x078: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfddde[0].crestmp.lo: 2456905728 ; 0x07c: USEC=0x0 MSEC=0x5a SECS=0x27 MINS=0x24 kfddde[0].failstmp.hi: 0 ; 0x080: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[0].failstmp.lo: 0 ; 0x084: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[0].timer: 0 ; 0x088: 0x00000000 kfddde[0].size: 5120 ; 0x08c: 0x00001400 --disk大小,由于au默认是1m,所以这里是5120m kfddde[0].srRloc.super.hiStart: 0 ; 0x090: 0x00000000 kfddde[0].srRloc.super.loStart: 0 ; 0x094: 0x00000000 kfddde[0].srRloc.super.length: 0 ; 0x098: 0x00000000 kfddde[0].srRloc.incarn: 0 ; 0x09c: 0x00000000 kfddde[0].dskrprtm: 0 ; 0x0a0: 0x00000000 kfddde[0].start0: 0 ; 0x0a4: 0x00000000 kfddde[0].size0: 5120 ; 0x0a8: 0x00001400 kfddde[0].used0: 76 ; 0x0ac: 0x0000004c kfddde[0].slot: 0 ; 0x0b0: 0x00000000 ..... kfddde[1].entry.incarn: 1 ; 0x1e4: A=1 NUMM=0x0 kfddde[1].entry.hash: 1 ; 0x1e8: 0x00000001 kfddde[1].entry.refer.number:4294967295 ; 0x1ec: 0xffffffff kfddde[1].entry.refer.incarn: 0 ; 0x1f0: A=0 NUMM=0x0 kfddde[1].dsknum: 1 ; 0x1f4: 0x0001 kfddde[1].state: 2 ; 0x1f6: KFDSTA_NORMAL kfddde[1].ddchgfl: 132 ; 0x1f7: 0x84 kfddde[1].dskname: DATADG_0003 ; 0x1f8: length=11 kfddde[1].fgname: DATADG_0003 ; 0x218: length=11 kfddde[1].crestmp.hi: 33042831 ; 0x238: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfddde[1].crestmp.lo: 2456905728 ; 0x23c: USEC=0x0 MSEC=0x5a SECS=0x27 MINS=0x24 kfddde[1].failstmp.hi: 0 ; 0x240: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[1].failstmp.lo: 0 ; 0x244: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[1].timer: 0 ; 0x248: 0x00000000 kfddde[1].size: 5120 ; 0x24c: 0x00001400 kfddde[1].srRloc.super.hiStart: 0 ; 0x250: 0x00000000 kfddde[1].srRloc.super.loStart: 0 ; 0x254: 0x00000000 kfddde[1].srRloc.super.length: 0 ; 0x258: 0x00000000 kfddde[1].srRloc.incarn: 0 ; 0x25c: 0x00000000 kfddde[1].dskrprtm: 0 ; 0x260: 0x00000000 kfddde[1].start0: 0 ; 0x264: 0x00000000 kfddde[1].size0: 5120 ; 0x268: 0x00001400 kfddde[1].used0: 76 ; 0x26c: 0x0000004c kfddde[1].slot: 0 ; 0x270: 0x00000000 .... kfddde[2].entry.incarn: 1 ; 0x3a4: A=1 NUMM=0x0 kfddde[2].entry.hash: 2 ; 0x3a8: 0x00000002 kfddde[2].entry.refer.number:4294967295 ; 0x3ac: 0xffffffff kfddde[2].entry.refer.incarn: 0 ; 0x3b0: A=0 NUMM=0x0 kfddde[2].dsknum: 2 ; 0x3b4: 0x0002 kfddde[2].state: 2 ; 0x3b6: KFDSTA_NORMAL kfddde[2].ddchgfl: 132 ; 0x3b7: 0x84 kfddde[2].dskname: DATADG_0002 ; 0x3b8: length=11 kfddde[2].fgname: DATADG_0002 ; 0x3d8: length=11 kfddde[2].crestmp.hi: 33042831 ; 0x3f8: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfddde[2].crestmp.lo: 2456905728 ; 0x3fc: USEC=0x0 MSEC=0x5a SECS=0x27 MINS=0x24 kfddde[2].failstmp.hi: 0 ; 0x400: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[2].failstmp.lo: 0 ; 0x404: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[2].timer: 0 ; 0x408: 0x00000000 kfddde[2].size: 5120 ; 0x40c: 0x00001400 kfddde[2].srRloc.super.hiStart: 0 ; 0x410: 0x00000000 kfddde[2].srRloc.super.loStart: 0 ; 0x414: 0x00000000 kfddde[2].srRloc.super.length: 0 ; 0x418: 0x00000000 kfddde[2].srRloc.incarn: 0 ; 0x41c: 0x00000000 kfddde[2].dskrprtm: 0 ; 0x420: 0x00000000 kfddde[2].start0: 0 ; 0x424: 0x00000000 kfddde[2].size0: 5120 ; 0x428: 0x00001400 kfddde[2].used0: 77 ; 0x42c: 0x0000004d kfddde[2].slot: 0 ; 0x430: 0x00000000 ... kfddde[3].entry.incarn: 1 ; 0x564: A=1 NUMM=0x0 kfddde[3].entry.hash: 3 ; 0x568: 0x00000003 kfddde[3].entry.refer.number:4294967295 ; 0x56c: 0xffffffff kfddde[3].entry.refer.incarn: 0 ; 0x570: A=0 NUMM=0x0 kfddde[3].dsknum: 3 ; 0x574: 0x0003 kfddde[3].state: 2 ; 0x576: KFDSTA_NORMAL kfddde[3].ddchgfl: 132 ; 0x577: 0x84 kfddde[3].dskname: DATADG_0000 ; 0x578: length=11 kfddde[3].fgname: DATADG_0000 ; 0x598: length=11 kfddde[3].crestmp.hi: 33042831 ; 0x5b8: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfddde[3].crestmp.lo: 2456905728 ; 0x5bc: USEC=0x0 MSEC=0x5a SECS=0x27 MINS=0x24 kfddde[3].failstmp.hi: 0 ; 0x5c0: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[3].failstmp.lo: 0 ; 0x5c4: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[3].timer: 0 ; 0x5c8: 0x00000000 kfddde[3].size: 5120 ; 0x5cc: 0x00001400 kfddde[3].srRloc.super.hiStart: 0 ; 0x5d0: 0x00000000 kfddde[3].srRloc.super.loStart: 0 ; 0x5d4: 0x00000000 kfddde[3].srRloc.super.length: 0 ; 0x5d8: 0x00000000 kfddde[3].srRloc.incarn: 0 ; 0x5dc: 0x00000000 kfddde[3].dskrprtm: 0 ; 0x5e0: 0x00000000 kfddde[3].start0: 0 ; 0x5e4: 0x00000000 kfddde[3].size0: 5120 ; 0x5e8: 0x00001400 kfddde[3].used0: 76 ; 0x5ec: 0x0000004c kfddde[3].slot: 0 ; 0x5f0: 0x00000000 ....
输出信息中的kfbh.type为KFBTYP_DISKDIR代表了这是一个磁盘目录。ASM中的磁盘的信息存储在上面输出内容的kfddde的区域，kfddde[0] 是关于磁盘0，kfddde[1]是关于磁盘1，以此类推。
以这种方式我们可以知道磁盘组中所有磁盘的信息，就像你看到的，大部分的信息都可以通过视图V$ASM_DISK去获取，而不需要通过kfed这种工具去查看。
使用kfed工具来判断磁盘目录位置
使用查询得到的磁盘目录AU分布如下:
SQL> select group_number,disk_number,name,path,state from v$asm_disk where group_number=3 order by 1,2;
GROUP_NUMBER DISK_NUMBER NAME PATH STATE
------------ ----------- ------------------------------ ------------------------------ ------------------------------
3 0 DATADG_0001 /dev/raw/raw11 NORMAL
3 1 DATADG_0003 /dev/raw/raw4 NORMAL
3 2 DATADG_0002 /dev/raw/raw3 NORMAL
3 3 DATADG_0000 /dev/raw/raw10 NORMAL
SQL> select x.xnum_kffxp "virtual extent",pxn_kffxp "physical extent",x.au_kffxp "au",x.disk_kffxp "disk #",d.name "disk name"
2 from x$kffxp x, v$asm_disk_stat d
3 where x.group_kffxp=d.group_number
4 and x.disk_kffxp=d.disk_number
5 and x.group_kffxp=3
6 and x.number_kffxp=2
7 order by 1, 2;
virtual extent physical extent au disk # disk name
-------------- --------------- ---------- ---------- ------------------------------------------------------------
0 0 3 2 DATADG_0002
0 1 3 0 DATADG_0001
0 2 3 1 DATADG_0003
上面的结果可以看出ASM的磁盘目录有三份镜像，当前磁盘目录的大小是3个物理extent（本例中也就是3个AU），再次强调，即使在一个normal冗余的磁盘组中，ASM的磁盘目录也有三份镜像。
读取磁盘头
[grid@jyrac1 ~]$ kfed read /dev/raw/raw3 | more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 2147483650 ; 0x008: disk=2 kfbh.check: 3693686872 ; 0x00c: 0xdc293058 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 2 ; 0x024: 0x0002 kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATADG_0002 ; 0x028: length=11 kfdhdb.grpname: DATADG ; 0x048: length=6 kfdhdb.fgname: DATADG_0002 ; 0x068: length=11 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33042831 ; 0x0a8: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfdhdb.crestmp.lo: 2456905728 ; 0x0ac: USEC=0x0 MSEC=0x5a SECS=0x27 MINS=0x24 kfdhdb.mntstmp.hi: 33042897 ; 0x0b0: HOUR=0x11 DAYS=0xe MNTH=0xc YEAR=0x7e0 kfdhdb.mntstmp.lo: 144833536 ; 0x0b4: USEC=0x0 MSEC=0x7f SECS=0xa MINS=0x2 kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 kfdhdb.dsksize: 5120 ; 0x0c4: 0x00001400 kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002 kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001 kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002 --allocate table kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 --file directory kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000 kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000 kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000 kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000 kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
allocate table元数据在第2个AU里面，而那么必然disk directory信息也在该AU里面，因为进行在读取alocate table信息时，必然要先读取disk directory。file directoryb也在第2个AU中
[grid@jyrac1 ~]$ kfed read /dev/raw/raw11 | grep kfdhdb.f1b1locn kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
由于1号文件总是开始在0号磁盘2号AU，记住这个位置：0号盘2号AU。这是ASM中定位文件的起点，它的作用，有点相当于磁盘上的引导区，在电脑开机后负责将OS启动起来。1号文件在最少情况下，至少有两个AU。在1号文件中，每个文件占用一个元数据块，存放自身的空间分布信息。每个元数据块大小是4K，一个AU是1M，哪么，每个AU中，可以存储256个文件的空间分布信息。这其中，0号盘2号AU中，全是元文件的信息。再具体一点，0号盘2号AU，第一个元数据块被系统占用，从第二个块开始，到255为止，共255个元数据块，对应索引号1至255的文件。其实，也就是全部的元文件了。也就是说0号盘2号AU，保存了全部元文件的空间分布信息。1号文件的第二个AU，从第一个块开始，保存256号文件。第二个块对应257号文件，等等。每次从ASM中读数据时，Oracle都要先读到1号文件，从中找出要读的目标文件在磁盘上的分布位置，然后再去读取相应的文件的数据。
由于磁盘目录的文件号为2,所以读取2号AU的2号块
[grid@jyrac1 ~]$ kfed read /dev/raw/raw11 aun=2 blkn=2 | more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 2 ; 0x004: blk=2 kfbh.block.obj: 1 ; 0x008: file=1 kfbh.check: 305881854 ; 0x00c: 0x123b62fe kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfffdb.node.incarn: 1 ; 0x000: A=1 NUMM=0x0 kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kfffdb.hibytes: 0 ; 0x00c: 0x00000000 kfffdb.lobytes: 1048576 ; 0x010: 0x00100000 kfffdb.xtntcnt: 3 ; 0x014: 0x00000003 kfffdb.xtnteof: 3 ; 0x018: 0x00000003 kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 kfffdb.flags: 1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0 kfffdb.fileType: 15 ; 0x021: 0x0f kfffdb.dXrs: 19 ; 0x022: SCHE=0x1 NUMB=0x3 kfffdb.iXrs: 19 ; 0x023: SCHE=0x1 NUMB=0x3 kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000 kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000 kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000 kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000 kfffdb.xtntblk: 3 ; 0x03c: 0x0003 kfffdb.break: 60 ; 0x03e: 0x003c kfffdb.priZn: 0 ; 0x040: KFDZN_COLD kfffdb.secZn: 0 ; 0x041: KFDZN_COLD kfffdb.ub2spare: 0 ; 0x042: 0x0000 kfffdb.alias[0]: 4294967295 ; 0x044: 0xffffffff kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff kfffdb.strpwdth: 0 ; 0x04c: 0x00 kfffdb.strpsz: 0 ; 0x04d: 0x00 kfffdb.usmsz: 0 ; 0x04e: 0x0000 kfffdb.crets.hi: 33042831 ; 0x050: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfffdb.crets.lo: 2457465856 ; 0x054: USEC=0x0 MSEC=0x27d SECS=0x27 MINS=0x24 kfffdb.modts.hi: 33042831 ; 0x058: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0 kfffdb.modts.lo: 2457465856 ; 0x05c: USEC=0x0 MSEC=0x27d SECS=0x27 MINS=0x24 kfffdb.dasz[0]: 0 ; 0x060: 0x00 kfffdb.dasz[1]: 0 ; 0x061: 0x00 kfffdb.dasz[2]: 0 ; 0x062: 0x00 kfffdb.dasz[3]: 0 ; 0x063: 0x00 kfffdb.permissn: 0 ; 0x064: 0x00 kfffdb.ub1spar1: 0 ; 0x065: 0x00 kfffdb.ub2spar2: 0 ; 0x066: 0x0000 kfffdb.user.entnum: 0 ; 0x068: 0x0000 kfffdb.user.entinc: 0 ; 0x06a: 0x0000 kfffdb.group.entnum: 0 ; 0x06c: 0x0000 kfffdb.group.entinc: 0 ; 0x06e: 0x0000 kfffdb.spare[0]: 0 ; 0x070: 0x00000000 kfffdb.spare[1]: 0 ; 0x074: 0x00000000 kfffdb.spare[2]: 0 ; 0x078: 0x00000000 kfffdb.spare[3]: 0 ; 0x07c: 0x00000000 kfffdb.spare[4]: 0 ; 0x080: 0x00000000 kfffdb.spare[5]: 0 ; 0x084: 0x00000000 kfffdb.spare[6]: 0 ; 0x088: 0x00000000 kfffdb.spare[7]: 0 ; 0x08c: 0x00000000 kfffdb.spare[8]: 0 ; 0x090: 0x00000000 kfffdb.spare[9]: 0 ; 0x094: 0x00000000 kfffdb.spare[10]: 0 ; 0x098: 0x00000000 kfffdb.spare[11]: 0 ; 0x09c: 0x00000000 kfffdb.usm: ; 0x0a0: length=0 kfffde[0].xptr.au: 3 ; 0x4a0: 0x00000003 kfffde[0].xptr.disk: 2 ; 0x4a4: 0x0002 kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0 kfffde[0].xptr.chk: 43 ; 0x4a7: 0x2b kfffde[1].xptr.au: 3 ; 0x4a8: 0x00000003 kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000 kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0 kfffde[1].xptr.chk: 41 ; 0x4af: 0x29 kfffde[2].xptr.au: 3 ; 0x4b0: 0x00000003 kfffde[2].xptr.disk: 1 ; 0x4b4: 0x0001 kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0 kfffde[2].xptr.chk: 40 ; 0x4b7: 0x28 kfffde[3].xptr.au: 4294967295 ; 0x4b8: 0xffffffff kfffde[3].xptr.disk: 65535 ; 0x4bc: 0xffff kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0 kfffde[3].xptr.chk: 42 ; 0x4bf: 0x2a kfffde[4].xptr.au: 4294967295 ; 0x4c0: 0xffffffff kfffde[4].xptr.disk: 65535 ; 0x4c4: 0xffff kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0 kfffde[4].xptr.chk: 42 ; 0x4c7: 0x2a kfffde[5].xptr.au: 4294967295 ; 0x4c8: 0xffffffff
kfffde，是结构数组。由于我这里磁盘目录有三份镜像，kfffde[0]的数据元素，
存放了2号文件第一个AU的位置。kfffde[1]存放了2号文件第二个AU位置，kfffde[2]存放了2号文件第三个AU位置等等，依次类推。我们来看一下上面的信息：
kfffde[0].xptr.au=3 --3号AU
kfffde[0].xptr.disk=2 --2号磁盘
上两个信息合起来，2号盘3号AU，这就是2号文件(磁盘目录)第一个AU的位置
kfffde[1].xptr.au=3 --3号AU
kfffde[1].xptr.disk=0 --0号磁盘
kfffde[2].xptr.au=3 --3号AU
kfffde[2].xptr.disk=1 --1号磁盘
上面的信息显示了2号文件的镜像副本存储在0号盘3号AU与1号盘的3号AU中。这与用查询x$kffxp视图所得到的元数据分布情况一致。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
