vxdisk resize may lead to user data corruption

Problem

With the introduction of the VxVM DLE ( Dynamic Lun Expansion ) feature, users are able to grow LUNs while still running production workload.  A bug in this feature may cause corruption in user data when VxVM fails to update block 0 ( disk label ) when using cdsdisk format.

Error Message

Corruption will look like block 0 (label) data

Example:

EMC-SYMMETRIX-5874 cyl 800 alt 2 hd 16 sec 256

Cause

VxVM command vxdisk resize fails to update block 0 (Label) .  The label is needed to be able to migrate lun from OS to OS .  ie: Solaris -- Linux --AIX --HP .   Since vxdisk resize fails to update the label running the following commands after growing lun will corrupt user data space with block 0 data.

vxdisk resize

vxdg flush 

Note : this is done during offline/clean routine in VCS

SYMPTOM:
Data corruption can be observed on a CDS (Cross-platform Data Sharing) disk,
as part of LUN resize operations. The following pattern would be found in the
data region of the disk.

<DISK-IDENTIFICATION> cyl <number-of-cylinders> alt 2 hd <number-of-tracks> sec
<number-of-sectors-per-track>

DESCRIPTION:
The CDS disk maintains a SUN VTOC in the zeroth block and a backup label at the
end of the disk. The VTOC maintains the disk geometry information like number of
cylinders, tracks and sectors per track. The backup label is the duplicate of
VTOC and the backup label location is determined from VTOC contents. As part of
resize, VTOC is not updated to the new size, which results in the wrong
calculation of the backup label location. If the wrongly calculated backup label
location falls in the public data region rather than the end of the disk as
designed, data corruption occurs.

RESOLUTION:
Update the VTOC contents appropriately for LUN resize operations to prevent the
data corruption.

Solution

Applies To

VxVM 5.1SP1, 5.1SP1RP1, 5.1SP1RP2 and 5.1SP1RP2P2