The system crashes
A submirror has been taken offline and brought back online
A new submirror has been added
While the resynchronization takes place, the mirror remains readable and writable by users.
A mirror resynchronization ensures proper mirror operation by maintaining all submirrors with identical data, with the exception of writes in progress.
A mirror resynchronization should not be bypassed. You do not need to manually initiate a mirror resynchronization. This process occurs automatically.
When a new submirror is attached (added) to a mirror, all the data from another submirror in the mirror is automatically written to the newly attached submirror. Once the mirror resynchronization is done, the new submirror is readable. A submirror remains attached to a mirror until it is detached.
If the system crashes while a resynchronization is in progress, the resynchronization is restarted when the system finishes rebooting.
During a reboot following a system failure, or when a submirror that was offline is brought back online, Solaris Volume Manager performs an optimized mirror resynchronization. The metadisk driver tracks submirror regions. This functionality enables the metadisk driver to know which submirror regions might be out-of-sync after a failure. An optimized mirror resynchronization is performed only on the out-of-sync regions. You can specify the order in which mirrors are resynchronized during reboot. You can omit a mirror resynchronization by setting submirror pass numbers to zero. For tasks associated with changing a pass number, see Example 11–15.
Following the replacement of a slice within a submirror, Solaris Volume Manager performs a partial mirror resynchronization of data. Solaris Volume Manager copies the data from the remaining good slices of another submirror to the replaced slice.
The resynchronization process affects both the performance of a system, as well as the user's ability to perform tasks. For example, resynchronizations impact the I/O performance and the response time of a system. Additionally, during a resynchronization process, a disk set cannot be released from a host. In another example, if a volume is attached by mistake, the volume cannot be released until the resynchronization has completed. Because of situations such as these, allowing a resynchronization process to complete is not always advantageous.
The metasync -c volume command cancels the resynchronization process on a given volume. The following functionality is associated with canceling resynchronization processes:
Canceled resynchronization processes are logged by using the syslog utility
After a reboot, any canceled resynchronization process is resumed from the point that it stopped
When a disk set is taken, any canceled resynchronization process within that disk set resumes automatically from the point of the cancellation
A canceled resynchronization process can be resumed manually from the point that it stopped by issuing the metasync volume command.
For the tasks associated with canceling and resuming resynchroniztion processes using the metasync command, see How to Cancel a Volume Resynchronization Process and How to Resume a Volume Resynchronization Process.