248 Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1
7.1.6  Mirrored volumes
IBM Spectrum Virtualize offers the capability to mirror volumes, which means that a single 
volume presented to a host can have two physical copies. Each volume copy can belong to 
a different pool, and each copy has the same virtual capacity as the volume. 
When a server writes to a mirrored volume, the storage system writes the data to both copies. 
When a server reads a mirrored volume, and the volume copies are synchronized, the system 
reads the data from the primary copy (in the management GUI the primary volume copy is 
marked by an asterisk [*]). 
If one of the mirrored volume copies is temporarily unavailable (for example, because the 
storage system that provides the pool is unavailable), the volume remains accessible to 
servers. The system remembers which areas of the volume were modified after loss of 
access to a volume copy and resynchronizes only these areas when both copies are 
available.
The use of mirrored volumes has the following consequences:
/SM590000Improves availability of volumes by protecting them from a single storage system failure.
/SM590000Enables concurrent maintenance of a storage system that does not natively support 
concurrent maintenance.
/SM590000Provides an alternative method of data migration.
/SM590000Enables conversion between fully allocated volumes and thin-provisioned volumes.
/SM590000Enables space reclamation of thin-provisioned volumes.
The two copies of a mirrored volume typically are allocated from separate storage pools 
backed by different physical hardware. Volume copies are identified in the GUI by a copy ID, 
which can have value 0 or 1. Copies of the volume can be split, which provides a point-in-time 
copy of a volume. 
Note: The striping effect occurs when multiple logical volumes that are defined on a set of 
physical storage devices (MDisks) store their metadata or file system transaction log on the 
same physical device (MDisk). 
Because of the way the file systems work, many I/O to file system metadata disk regions 
exist. For example, for a journaling file system, a write to a file might require two or more 
writes to the file system journal; at minimum, one to make a note of the intended file 
system update, and one marking successful completion of the file write. 
If multiple volumes (each with its own file system) are defined on the same set of MDisks, 
and all (or most) of them store their metadata on the same MDisk, a disproportionately 
large I/O load is generated on this MDisk, which can result in suboptimal performance of 
the storage system. Pseudo-randomly allocating first MDisk for new volume extent 
allocation minimizes probability, that file systems that are created on these volumes places 
their metadata regions on the same physical MDisk.
Note: Volume mirroring is not a true disaster recovery (DR) solution because both copies 
are accessed by the same node pair and addressable by only a single cluster. However, if 
correctly planned, it can improve availability.