resolving "Data Corruption Protection Activated"

[p033692]

Hello, recently I've noticed a number of servers giving the error below:

VxVM vxdisk ERROR V-5-1-14519  Data Corruption Protection Activated - User Corrective Action Needed
VxVM vxdisk INFO V-5-1-14521  To recover, first ensure that the OS device tree is up to date (requires OS specific commands).
VxVM vxdisk INFO V-5-1-14520  Then, execute 'vxdisk rm' on the following devices before reinitiating device discovery: <device list follows here...>

This occurs after discovering new EMC disk and following up with vxdisk scandisks, and it seems to stop me from scanning for new disks.  I've followed usual steps of presenting and scanning for san disk, have never seen this issue before but now it's showing up on multiple servers.

Found this interesting forum discussion - "LUN Removal Process - Solaris 10 U8 / Storage Foundation 5.1 / PowerPath 5.3" and followed the steps for removing luns, thinking this might be the issue, but rescanning results in same error.

A reboot of a production server where I was having this problem did seem to fix it, but as I have about 8 other production boxes and as many development boxes it's not practical to try to reboot them all - big business impact.

Have tried researching quite a bit online, any ideas or help?

[Gaurav_S]

Hello,

"Data Corruption Protection Activated"

Symantec introduced a new feature in 5.0 MP3 onwards called "Data Corruption Prevention Activity" (DCPA) feature which basically puts a bubble around each DMP device.

The Data Corruption Prevention Activity (DCPA) feature will assist with safeguarding your data.

The data corruption protection feature actually works to prevent corruption and is a proactive message, rather than a warning about specific corruption !

Using the bubble protector technology surrounding all the existing DMP nodenames, the product prevents other paths merging with it from another physical device. This dramatically helps to reduce the chances of data corruption, when the customer fails to perform the correct and essential steps surrounding the complex lun removal and storage provisioning process.

Prior to 5.0 MP3 it is very difficult to conclude if a step during the lun removal process failed or was accidentally missed.

Many articles around this on Symantec site, see following:

http://www.symantec.com/docs/TECH76355

http://www.symantec.com/docs/TECH128862

One of very fine "HowTo" article:

http://www.symantec.com/docs/HOWTO35877

I hope these will answer your questions...

Gaurav

[p033692]

Following the steps in TECH128862 seems to have solved my problem - vxdisk scandisks runs fine and I was able to complete the discovery of storage, config, etc.  Thanks very much for your help.

Couple questions if I may.  I noticed a warning at one point while suppressing a path that this action might interrupt access to the device, and to take precautions.  I'm guessing that's because I suppressed first the path on the first controller, followed by the second controller, on a device that was part of a disk group (not imported).  As my app was down, I proceded, but could I have also suppressed only one path at a time, and would that have had the same success but without the danger of crashing an app due to both storage pathways being suppressed?  Just curious.

Also, I see many articles referencing /etc/vx/disk.info.  Not familiar with it but I see it's a text file (with a backup disk.info.old), seems refreshed at last boot, possibly contains storage path info for persistance across reboots?  Where it's recommended to mv and recreate this file, is there some danger to doing this with applications up?  Will storage paths be lost until the file is recreated?

Thanks again

[Gaurav_S · Accepted solution]

Hello,

to answer first part, yes thats quite possible, the warning is actually pointing to the same reason what you are guessing, you shouldn't accidently supress all the paths which may result in an outage.. To my belief (though I have not tried recently), vxvm will warn you befre supress however it won't care if that was the last surviving path....

to answer second part, /etc/vx/disk.info file use to contain the device mappings... this was there till 5.0 however 5.1 seems to have removed this file.. you can move this file while your applications are up, it won't have any impact... once you restart vxconfigd daemon, this file will be generated automatically..

moving disk.info is mostly recommended in device tree related issues for e.g, disk names not matching or not appearing as expected.... something changed after reboot ... or new luns not visible.. its common step for device tree cleanup which can be done online.

hope this answers..

Gaurav