Filter
Top Products
74 Understanding Veritas Volume Manager
FastResync
different effects on the map that FastResync uses to track changes to the
original volume:
■ For a version 20 DCO volume, the size of the map is increased and the size of
the region that is tracked by each bit in the map stays the same.
■ For a version 0 DCO volume, the size of the map remains the same and the
region size is increased.
In either case, the part of the map that corresponds to the grown area of the
volume is marked as “dirty” so that this area is resynchronized. The
snapback
operation fails if it attempts to create an incomplete snapshot plex. In such
cases, you must grow the replica volume, or the original volume, before invoking
any of the commands
vxsnap reattach, vxsnap restore, or vxassist snapback.
Growing the two volumes separately can lead to a snapshot that shares physical
disks with another mirror in the volume. To prevent this, grow the volume after
the
snapback command is complete.
FastResync limitations
The following limitations apply to FastResync:
■ Persistent FastResync is supported for RAID-5 volumes, but this prevents
the use of the relayout or resize operations on the volume while a DCO is
associated with it.
■ Neither non-persistent nor persistent FastResync can be used to
resynchronize mirrors after a system crash. Dirty region logging (DRL),
which can coexist with FastResync, should be used for this purpose. In
VxVM 4.0 and later releases, DRL logs may be stored in a version 20 DCO
volume.
■ When a subdisk is relocated, the entire plex is marked “dirty” and a full
resynchronization becomes necessary.
■ If a snapshot volume is split off into another disk group, non-persistent
FastResync cannot be used to resynchronize the snapshot plexes with the
original volume when the disk group is rejoined with the original volume’s
disk group. Persistent FastResync must be used for this purpose.
■ If you move or split an original volume (on which persistent FastResync is
enabled) into another disk group, and then move or join it to a snapshot
volume’s disk group, you cannot use
vxassist snapback to resynchronize
traditional snapshot plexes with the original volume. This restriction arises
because a snapshot volume references the original volume by its record ID at
the time that the snapshot volume was created. Moving the original volume
to a different disk group changes the volume’s record ID, and so breaks the