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-24

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

Article Type
Technical Solution

Product(s)

Show all

Languages

Show all

Problem

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

Source	ETrack
Value	2349352
Description	During LUN provisioning in single path IO mode environment a data corruption is observed