When storing data redundantly
and using mirrored or RAID-5 volumes, VxVM ensures that all
copies of the data match exactly. However, under certain conditions
(usually due to complete system failures), some redundant data on
a volume can become inconsistent or unsynchronized. The mirrored
data is not exactly the same as the original data. Except for normal
configuration changes (such as detaching and reattaching a plex),
this can only occur when a system crashes while data is being written
to a volume.
Data is written to the mirrors of a volume in parallel, as
is the data and parity in a RAID-5 volume. If a system crash occurs
before all the individual writes complete, it is possible for some
writes to complete while others do not. This can result in the data
becoming unsynchronized. For mirrored volumes, it can cause two
reads from the same region of the volume to return different results,
if different mirrors are used to satisfy the read request. In the
case of RAID-5 volumes, it can lead to parity corruption and incorrect
data reconstruction.
VxVM needs to ensure that all mirrors contain exactly
the same data and that the data and parity in RAID-5 volumes agree.
This process is called volume resynchronization. For volumes that
are part of disk groups that are automatically imported at boot
time (such as rootdg), the resynchronization process takes place
when the system reboots.
Not all volumes require resynchronization after a system failure. Volumes
that were never written or that were quiescent (that is, had no active
I/O) when the system failure occurred could not have had outstanding
writes and do not require resynchronization.
Dirty
Flags |
 |
VxVM records
when a volume is first written to and marks it as dirty. When a
volume is closed by all processes or stopped cleanly by the administrator,
and all writes have been completed, VxVM removes the dirty
flag for the volume. Only volumes that are marked dirty when the system
reboots require resynchronization.
Resynchronization
Process |
|
The process of resynchronization
depends on the type of volume. RAID-5 volumes that contain RAID-5
logs can "replay" those logs. If no logs are available,
the volume is placed in reconstruct-recovery mode and all parity
is regenerated. For mirrored volumes, resynchronization is done by
placing the volume in recovery mode (also called read-writeback recovery
mode). Resynchronization of data in the volume is done in the background.
This allows the volume to be available for use while recovery is
taking place.
The process of resynchronization can impact system performance.
The recovery process reduces some of this impact by spreading the
recoveries to avoid stressing a specific disk or controller.
For large volumes or for a large number of volumes, the resynchronization
process can take time. These effects can be
addressed by using dirty region logging (DRL) and FastResync (fast
mirror resynchronization) for mirrored volumes, or by ensuring that
RAID-5 volumes have valid RAID-5 logs. See the following sections, “Dirty
Region Logging (DRL)” and “FastResync” for more information.
For volumes used by database applications, the SmartSync™ Recovery Accelerator
can be used (see “SmartSync
Recovery Accelerator”).
Printable version
