===========================
Normally the default data change object (DCO) size set by VERITAS Volume Manager (VxVM) is sufficient.

 

However, there may be times when it is desirable to change the size of a DCO.  In this case, the new DCO size can be estimated with the following information.

Regardless of the size of the volume, the default DCO length is 132 blocks of 512 bytes each.

 

Each DCO is comprised of 33 maps. Regardless of the size of the DCO, it always has 33 maps. Each "map" will track changes made to the volume while "a particular plex" is detached.  A DCO map tracks volume changes by dividing the volume disk space into regions. Each block belongs to one of these regions. When a plex is detached and a volume block is updated, a map bit is set representing that block's region.  When the plex is snapped-back or re-attached, only those regions having the corresponding bits set will be synchronized.  

ACTUAL CALCULATION

==========================
The size of the DCO determines the size of the maps. The size of the maps determines the size of the regions.  In the case of the default size of 132 blocks, each map will be 4 blocks in size:

132 blocks / 33 maps  =4 blocks per map

If the map is 4 blocks in length, it will have 16,384bits to track 16,384 changed regions:
 

4 blocks * 512 bytes * 8 bits =16,384 bits (or regions)
 

If a volume is 20 gigabytes in size (41,943,040 blocks),the DCO map will allocate 2,560 blocks per region:  
 

Thus, if any one of these 2,560 blocks changes, the bit for that region is set and the whole 2,560 block region will requirere synchronization when the plex is reattached.

If the DCO size were 264blocks, each map would be 8 blocks in length:  
 

This will yield "smaller" regions:
 

KEY TAKEAWAY

==========================
A larger DCO will yield smaller regions. Having smaller regions will allow faster resynchronization per region.

 

However, it may also require that more regions be resynchronized since more regions may be marked dirty. But, in this example, resyncing two smaller regions would not really take any more overhead than resyncing one larger region of twice the size.

It will be necessary to anticipate what ratio of blocks per volume might change before the plex gets reattached, and determine the DCO size from there.  

 

For example, if one anticipates a large ratio of block changes, a smaller DCO might make sense.  This would allow larger regions.  Most of the changed blocks will probably fall into only a few regions.  If one anticipates only a small ratio of block changes, then a larger DCO with smaller regions might be preferred.  Now only a few smaller regions will need re-synchronization.

Of course, the other obvious reason to increase the DCO size would be if the volume were much larger.  If the volume is very large, one may want a larger DCO to get smaller regions.  Otherwise, a very large volume will have very large regions.

CREATING A CUSTOM DCO SIZE

==========================
The default DCO size can be set to a non-default size when the DCO is created with vxassist and dcolen (DCO length):

# vxassist -g thisdg make vol01 100glogtype=dco dcolen=264

Or the DCO can be added after the volume is created using