Lun addition followed by a "vxdctl enable" operation can cause data corruption, when Volume Manager's (VxVM) configuration daemon, vxconfigd, is migrating disk-access names (DANAME) with simultaneous active I/O on the devices

Article:TECH158119  |  Created: 2011-04-14  |  Updated: 2012-05-23  |  Article URL http://www.symantec.com/docs/TECH158119
Article Type
Technical Solution

Product(s)

Issue



Data corruption can occur in any one of the following configurations, when new LUNs are provisioned or removed under VxVM, while IOs are in progress.

1. The VxVM device naming scheme is EBN (enclosure based naming) and persistence=off
2. The VxVM device is configured with single path
3. The VxVM device is controlled by non-VxVM DMP Multipathing Driver (Ex: MPXIO, MPIO et.,) which presents only one logical path to the OS
 

Error



The following "WARNING" messages can be seen

vxio: [ID 914260 kern.notice] NOTICE: VxVM vxio V-5-0-1046 changing UDID for disk <DANAME>

vxio: [ID 718197 kern.notice] NOTICE: VxVM vxio V-5-0-1056 change disk <DANAME> has a non-unique UDID


Cause



There is a possibility of change in name of the DA records, when LUNs are removed or added followed by the following commands, since the persistence naming is OFF.

(a) vxdctl enable
(b) vxdisk scandisks
 
Executing the above commands claims all the devices and builds the attribute list for all the claimed disks. This attribute list is built according to the new names. The new attribute list is used to refresh the in core DA records at a point in the code, where the DA names are not yet updated with new names. Thus the DA refreshes lead to an incorrect device mapping. In this process of updating, at later point of time the change in DA name is recognized and accordingly the device number is updated with correct device number. Thus an intermittent data corruption can be observed if IOs are in progress during this process of DA record updating.

Solution



Set disk to persistence naming this problematic vxvm code can be avoided.

NOTE:  PLEASE MAKE SURE ALL I/O's TO VOLUMES ARE STOPPED.  FILE SYSTEMS MUST BE UNMOUNTED TO ENSURE THE PROBLEMATIC CODE IS AVOIDED.

Please run the following commands to avoid the problem:
 
#vxddladm set namingscheme=ebn persistance=yes
 
Check the following file is created
#cat /etc/vx/disk.info
 
Example:
bash-3.00# cat /etc/vx/disk.info
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030304335 c4t60060480000190301018533030304335d0 0x4ec0100 0x2 emc1_00c5 EMC 000190301018
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030304338 c4t60060480000190301018533030304338d0 0x4ec00b0 0x2 emc1_00c8 EMC 000190301018
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030323442 c4t60060480000190301018533030323442d0 0x4ec0058 0x2 emc1_024b EMC 000190301018
FUJITSU%5FMAY2073RCSUN72G%5FDISKS%5F500000E011FF7850 c0t0d0 0x4ec0000 0x2 disk_1 Disk DISKS
 
The file dmppolicy.info should reflect persistence=yes.
#/etc/vx/dmppolicy.info
 
Example:
cat dmppolicy.info
arraytype
#
arrayname
#
enclosure
#
naming
scheme=ebn persistence=yes mode=default lowercase=yes use_avid=yes
 
This issues can be tracked through Etrack (e2349352 )
 
This issue is fixed in the following patches:
- 5.1SP1RP2 on Solaris, Linux and AIX
- 5.0.1RP3P2 on HP-UX 11.31
- 5.0MP2RP3P1 on HP-UX 11.23
- 5.0MP3RP5HF1 on Solaris
- 5.0MP4RP1HF7 on Linux
- 5.0MP3RP5HF9 on AIX

Supplemental Materials

SourceETrack
Value2349352
Description

During LUN provisioning in single path IO mode environment a data corruption is observed



Article URL http://www.symantec.com/docs/TECH158119


Terms of use for this information are found in Legal Notices