ASM – CANDIDATE or FORMER disks show FREE_MB as 0

Solaris 10 update 8, with Oracle 10gR2 (

Normally in Solaris when we prepare a disk for ASM use,

a. we format the disk
b. create hog partition
c. change permission to oracle:dba & use the disk

I did all of above and checked, if the disk size is correctly shown

SQL> select group_number, path, header_status, total_mb, free_mb from v$asm_disk

———- —————————————- ———- ———- ———-
0 /dev/rdsk/c2t200400A0B81843A2d2s6 CANDIDATE 255988 0
3 /dev/rdsk/c2t200400A0B81843A2d7s6 MEMBER 255988 130742
3 /dev/rdsk/c2t200400A0B81843A2d8s6 MEMBER 255988 130742

It was showing, TOTAL_MB correctly, but not the FREE_MB. I was expecting it to be same. Checked with kfed for further details

oracle$> kfed read ‘/dev/rdsk/c2t200400A0B81843A2d2s6’

kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0
kfbh.check: 0 ; 0x00c: 0x00000000
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000

I guess, as the metadata is not yet written to the disk header (KFBTYP_INVALID), it is not showing the disk space usage (FREE_MB). But when I checked same for the FORMER disk, I saw the same problem i.e. FREE_MB was still 0 (whereas now the disk is free to use)

Different behavior is seen on HPUX

HPUX 11.31, with Oracle 11gR1 (

SQL> select group_number, path, header_status, total_mb, free_mb from v$asm_disk

———— ———————————– ———— ———- ———-
0 /dev/vx/rdsk/asmdg7/asmvol FORMER 0 0
1 /dev/vx/rdsk/asmdg19/asmvol MEMBER 4999 3182

Here, both TOTAL_MB & FREE_MB are shown as 0 for CANDIDATE or FORMER disks.

Although kfed output show, disk size (kfdhdb.dsksize)

kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 4 ; 0x027: KFDHDR_FORMER
kfdhdb.dskname: DUMMY_0000 ; 0x028: length=10
kfdhdb.grpname: DUMMY ; 0x048: length=5
kfdhdb.fgname: DUMMY_0000 ; 0x068: length=10
kfdhdb.capname: ; 0x088: length=0
kfdhdb.secsize: 1024 ; 0x0b8: 0x0400
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 4999 ; 0x0c4: 0x00001387

Following Metalink notes describe similar behavior, if this view is queried from RDBMS instance.
Metalink Note 372274.1
Metalink Note 294325.1

But I’m seeing this from ASM instance itself.

Not sure, if it is a BUG or Oracle doesn’t intentionally update these columns!!

This entry was posted in Oracle Automatic Storage Management and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s