Error Message

After a disk is resized using the vxdisk resize command, its backup information becomes stale inside the diskinfo files in the CBR directory (e.g. /etc/vx/cbr/bk/diskgroupid/diskgroupid.diskinfo).  

For example, in the CBR diskinfo file the resized disk has the following configuration.

UUID=HITACHI%5FOPEN-V%5F00000%5F2000
Device:    tagmastore-usp0_2000
devicetag: tagmastore-usp0_2000
type:      auto
hostid:    hostABC
disk:      name=datadg01 id=1292258843.26.hostABC
group:     name=datadg id=1292259972.62.hostABC
info:      format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags:     online ready private autoconfig autoimport imported thinrclm
pubpaths:  block=/dev/vx/dmp/tagmastore-usp0_2000s3 char=/dev/vx/rdmp/tagmastore-usp0_2000s3
guid:      {a8e54692-06d8-11e0-a3fb-99e27672b66b}
udid:      HITACHI%5FOPEN-V%5F00000%5F2000
site:      -
version:   3.1
iosize:    min=512 (bytes) max=1024 (blocks)
public:    slice=3 offset=65792 len=2201819168 disk_offset=0       <<< stale data with size and disk offset before the LUN resizing
private:   slice=3 offset=256 len=65536 disk_offset=0
update:    time=1292259972 seqno=0.7
ssb:       actual_seqno=0.0
headers:   0 240
configs:   count=1 len=51360
logs:      count=1 len=4096
Defined regions:
config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
log      priv 051424-055519[004096]: copy=01 offset=000000 enabled
lockrgn  priv 055520-055663[000144]: part=00 offset=000000
Multipathing information:
numpaths:  32
sdgv    state=enabled
sdcu    state=enabled
sdu     state=enabled
.....

But according to the vxdisk output, the disk is now having a new size and disk offset.

# vxdisk -v list hitachi_usp-v0_2000
Device:    hitachi_usp-v0_2000
devicetag: hitachi_usp-v0_2000
type:      auto
hostid:    hostABC
disk:      name=datadg01 id=1292258843.26.hostABC
group:     name=datadg id=1292259972.62.hostABC
info:      format=cdsdisk,privoffset=208,pubslice=3,privslice=3
flags:     online ready private autoconfig nohotuse noautoimport imported thinrclm
pubpaths:  block=/dev/vx/dmp/hitachi_usp-v0_2000s3 char=/dev/vx/rdmp/hitachi_usp-v0_2000s3
guid:      {a8e54692-06d8-11e0-a3fb-99e27672b66b}
udid:      HITACHI%5FOPEN-V%5F00000%5F2000
site:      -
version:   4.1
iosize:    min=512 (bytes) max=1024 (blocks)
public:    slice=3 offset=65744 len=3460234960 disk_offset=48     <<< different size and disk offset
private:   slice=3 offset=208 len=65536 disk_offset=48
update:    time=1386568833 seqno=0.118
ssb:       actual_seqno=0.0
headers:   0 240
configs:   count=1 len=51360
logs:      count=1 len=4096
Defined regions:
 config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
 config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
 log      priv 051424-055519[004096]: copy=01 offset=000000 enabled
 lockrgn  priv 055520-055663[000144]: part=00 offset=000000
Annotations:
 tag      udid_asl=HITACHI%5FOPEN-V%5F00000%5F2000
Multipathing information:
numpaths:   8
sddf            state=enabled
sdef            state=enabled
sdgf            state=enabled
sdez            state=enabled
sdf             state=enabled
sdba            state=enabled
sdy             state=enabled
sdbu            state=enabled

The problem is caused by the Etrack incident listed in the Supplemental Material section of this article.   Currently the vxconfigbackup program only checks if there is any change in the number of disks in the diskgroup or if any Disk Media (DM) records are renamed in the diskgroup.   If there is no change in the number of disks or no disk is renamed, then the disk information is not backed up.    Since the dynamic LUN resizing only changes the size of the disk, the current vxconfigbackup program will not backup the new information (sizes or disk offsets) but just copy the old disk information from previous backup.

As a workaround, use vxconfigbackup to update the disk group configuration backup.

1. Rename the CBR backup directory of the diskgroup, so that the vxconfigbackup program cannot find the old information and is forced to create a new full backup.

For example: 

# cd /etc/vx/cbr/bk
# mv diskgroup.diskgroupid diskgroup.diskgroupid.old

2. Run a manual vxconfigbackup.

Note: See this article for details on using vxconfigbackup:

"Using vxconfigbackup and vxprivutil to back up up the disk group configuration of the Veritas private region"

Link

A permanent solution will be available in the future VxVM patch releases through the listed Etrack incident.
 

Applies To

System running Veritas Volume Manager (VxVM) and problem occurs after a LUN is resized  using the vxdisk resize command.

After dynamic LUN resizing using vxdisk resize command, data in the disk information file (*.diskinfo) in the VxVM Configuration Backup and Restore (CBR) database become stale.  

ETrack: 3284888