Starting with version 12.1, ASM replicates the physically addressed metadata. This means that ASM maintains two copies of the disk header, the Free Space Table and the Allocation Table data. Note that this metadata is not mirrored, but replicated. ASM mirroring refers to copies of the same data on different disks. The copies of the physical metadata are on the same disk, hence the term replicated. This also means that the physical metadata is replicated even in an external redundancy disk group.
The Partnership and Status Table (PST) is also referred to as physically addressed metadata, but the PST is not replicated. This is because the PST is protected by mirroring – in normal and high redundancy disk groups.
Where is the replicated metadata
The physically addressed metadata is in allocation unit 0 (AU0) on every ASM disk. With this feature enabled, ASM will copy the contents of AU0 into allocation unit 11 (AU11), and from that point on, it will maintain both copies. This feature will be automatically enabled when a disk group is created with ASM compatibility of 12.1 or higher, or when ASM compatibility is advanced to 12.1 or higher, for an existing disk group.
If there is data in AU11, when the ASM compatibility is advanced to 12.1 or higher, ASM will simply move that data somewhere else, and use AU11 for the physical metadata replication.
Since version 11.1.0.7, ASM keeps a copy of the disk header in the second last block of AU1. Interestingly, in version 12.1, ASM still keeps the copy of the disk header in AU1, which means that now every ASM disk will have three copies of the disk header block.
Disk group attribute PHYS_META_REPLICATED
The status of the physical metadata replication can be checked by querying the disk group attribute PHYS_META_REPLICATED. Here is an example with the asmcmd command that shows how to check the replication status for disk group DATA:
Name Value
phys_meta_replicated true
The phys_meta_replicated=true means that the physical metadata for disk group DATA has been replicated.
The kfdhdb.flags field in the ASM disk header indicates the status of the physical metadata replication as follows:
- kfdhdb.flags = 0 – no physical data has been replicated
- kfdhdb.flags = 1 – physical data has been replicated
- kfdhdb.flags = 2 – physical data replication in progress
Once the flag is set to 1, it will never go back to 0.
Metadata replication in action
As stated earlier, the physical metadata will be replicated in disk groups with ASM compatibility of 12.1 or higher. Let’s first have a look at a disk group with ASM compatible set to 12.1:
Name Value
compatible.asm 12.1.0.0.0
$ asmcmd lsattr -G DATA -l phys_meta_replicated
Name Value
phys_meta_replicated true
This shows that the physical metadata has been replicated. Now verify that all disks in the disk group have the kfdhdb.flags set to 1:
kfdhdb.dskname: DATA_0000 ; 0x028: length=9
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
kfdhdb.dskname: DATA_0001 ; 0x028: length=9
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
kfdhdb.dskname: DATA_0002 ; 0x028: length=9
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
kfdhdb.dskname: DATA_0003 ; 0x028: length=9
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
This shows that all disks have the replication flag set to 1, i.e. that the physical metadata has been replicated for all disks in the disk group.
Let’s now have a look at a disk group with ASM compatibility 11.2, that is later advanced to 12.1:
2 disk ‘/dev/sdi1’
3 attribute ‘COMPATIBLE.ASM’=’11.2’;
Diskgroup created.
Check the replication status:
Name Value
Nothing – no such attribute. That is because the ASM compatibility is less than 12.1. We also expect that the kfdhdb.flags is 0 for the only disk in that disk group:
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: DG1_0000 ; 0x028: length=8
kfdhdb.grpname: DG1 ; 0x048: length=3
kfdhdb.flags: 0 ; 0x0fc: 0x00000000
Let’s now advance the ASM compatibility to 12.1:
Check the replication status:
Name Value
phys_meta_replicated true
The physical metadata has been replicated, so we should now see the kfdhdb.flags set to 1:
kfdhdb.dskname: DG1_0000 ; 0x028: length=8
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
The physical metadata should be replicated in AU11:
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: DG1_0000 ; 0x028: length=8
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
$ kfed read /dev/sdi1 aun=11 blkn=1 | grep type
kfbh.type: 2 ; 0x002: KFBTYP_FREESPC
$ kfed read /dev/sdi1 aun=11 blkn=2 | grep type
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
This shows that the AU11 has the copy of the data from AU0.
Finally check for the disk header copy in AU1:
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
This shows that there is also a copy of the disk header in the second last block of AU1.
Conclusion
ASM version 12 replicates the physically addressed metadata, i.e. it keeps the copy of AU0 in AU11 – on the same disk. This allows ASM to automatically recover from damage to any data in AU0. Note that ASM will not be able to recover from loss of any other data in an external redundancy disk group. In a normal redundancy disk group, ASM will be able to recover from a loss of any data in one or more disks in a single failgroup. In a high redundancy disk group, ASM will be able to recover from a loss of any data in one or more disks in any two failgroups.
Leave a Reply