Under certain limited conditions, "vxassist addlog" will create a zero length Data Change Map (DCM) on striped-mirror volumes and cause the secondary Replicated Volume Group (RVG) to go out of sync if a resync was performed.

Article:TECH11234  |  Created: 2001-01-22  |  Updated: 2002-01-05  |  Article URL http://www.symantec.com/docs/TECH11234
Article Type
Technical Solution

Environment

Issue



Under certain limited conditions, "vxassist addlog" will create a zero length Data Change Map (DCM) on striped-mirror volumes and cause the secondary Replicated Volume Group (RVG) to go out of sync if a resync was performed.

Solution



In VERITAS Storage Replicator for Volume Manager (SRVM) versions 3.0.2 and 3.1, a Data Change Map (DCM) that is added to a striped-mirror volume using the vxassist command,  such as:
      
# vxassist -g <diskgroup> addlog <volume> logtype=dcm

will have a length of 0.  "vxassist" will not report any errors, but this problem can be identified using the vxprint command.  For example,

# vxprint -l v2

Volume:  v2
info:         len=204800
type:        usetype=fsgen
state:       state=ACTIVE kernel=ENABLED cdsrecovery=0/0 (clean)
assoc:      plexes=v2-04
policies:   read=SELECT (prefer v2-04) exceptions=GEN_DET_SPARSE
flags:        closed writeback
logging:    type=DCM loglen=0 serial=0/0 (enabled)
apprecov: seqno=0/0
recov_mode=default
recov_id=0
device:       minor=20003 bdev=226/20003 cdev=226/20003 path=/dev/vx/dsk/dg/v2
perms:        user=root group=root mode=0600

This issue has been reported as incident # 51403 and has been fixed in VERITAS Volume Replicator (VVR) 3.1.1 (called VERITAS Storage Replicator for Volume Manager, SRVM,  prior to version 3.1.1) .  It does not occur on non-layered volumes, or on layered volumes where the DCMs are created at the same time as the volumes, for example, with the command:

# vxassist -g <diskgroup> make <volume> <length> layout=stripe-mirror logtype=dcm

In a Replicated Volume Group (RVG) with zero length DCMs, if an attempt is made to autosync the rlink, the vxrlink command fails with the message:

vxvm:vxrlink: ERROR:  Log load to volume v1 failed: Not owner
vxvm:vxrlink: ERROR:  could not load log for volume v1

or dumps core due to Bus Error (signal 10).

If the rlink overflows and a subsequent resync is done, the resync finishes very quickly but in fact does not perform a resync. If a resync was ever performed on such a volume, the secondary RVG is out of sync. After performing the corrective actions outlined below, detach the rlink and autosync it, using the commands:

# vxrlink -g <diskgroup> det <rlink>
# vrlink -g <diskgroup> -a att <rlink>

or do a checkpoint attach.

The recommended solution is to remove all the zero length DCMs, upgrade to VVR 3.1.1, and add new DCMs.  If it is impossible to upgrade, the problem can be fixed by converting the data volumes of the RVG to mirror-stripe, adding the DCMs and then converting the data volumes back to stripe-mirror, using the following procedure:

# vxedit -g <diskgroup> set srlprot=off <rlink>
# vxassist -g <diskgroup> remove log <volume> nlog=0
# vxassist -g <diskgroup> convert <volume> layout=mirror-stripe

reboot the machine

# vxassist -g <diskgroup> addlog <volume> logtype=dcm
# vxassist -g <diskgroup> convert <volume> layout=stripe-mirror
# vxedit -g <diskgroup> set srlprot=dcm <rlink>

If you have any questions about this procedure or require additional assistance please contact VERITAS Techncial Support.  



Supplemental Materials

SourceDEFECT
Value51403
Descriptionadding a dcm causes a ted_assert

Legacy ID



236859


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


Terms of use for this information are found in Legal Notices