If either of the backend storage systems corrupts the data, the host is at risk of reading that  corrupted data in the same way as for any other volume. Therefore, before you perform  maintenance on a storage system that might affect the data integrity of one copy, it is  important to check that both volume copies are synchronized. Then, remove that volume copy  before you begin the maintenance. For example, the scenario applies if you must zero the  data on the disks that the storage system is providing. Use cases: SAN Volume Controller volume mirroring with FlashSystem Depending on the storage system that is chosen for each of the two volume mirror copies,  certain details must be considered to meet the high performance and low latency  expectations of the solution.  This section describes usage scenarios for the SAN Volume Controller volume mirroring  when virtualizing one or more FlashSystem storage systems. Also described is the potential  benefits and preferred practices for each scenario. Use case 1: Volume mirroring between two FlashSystem storage systems This case is the basic scenario for SAN Volume Controller volume mirroring because both  copies are on the same type of storage systems. In this scenario, performance is not  expected to be affected in a failure if the two subsystems are close to the SAN Volume  Controller nodes.  This scenario indicates a non-stretched cluster setup. In this case, FC link latency is not likely  to present an issue. The default configuration for preferred node, primary copy, and mirroring  priority is simplified. Note:  Volume mirroring does not contribute to host-side latency on the front end. Volume  mirroring destaging is handled by the back end and is transparent to hosts. The time that it  takes to cache mirror write I/Os must be considered if the nodes of a stretched cluster are  far apart. For more information, see  IBM System Storage SAN Volume Controller and  Storwize V7000 Best Practices and Performance Guidelines , SG24-7521. http://www.redbooks.ibm.com/abstracts/sg247521.html?Open Use case 2: Volume mirroring between a FlashSystem and a non-flash storage  system In this scenario, which is often adopted for cost-reduction reasons, plan to avoid the penalty  that is represented by the slowest subsystem to the overall I/O latency. Consider the following  suggestions: GLYPH<SM590000> The primary copy of each mirrored volume must be set for the copy that is in the  FlashSystem subsystem so that all the reads are directed to it by SAN Volume Controller.  This configuration is commonly referred to as a  preferred read  configuration. See sections  6.5, “FlashSystem 900 preferred read and configuration examples” on page 172 and 11.3,  “Preferred read” on page 401. GLYPH<SM590000> If both subsystems are close to the SAN Volume Controller nodes, which is a  non-Stretched Cluster  setup, the  -mirrorwritepriority  flag for the mirrored volume must  be set to  latency . Therefore, destaging to the volume copy in the slowest subsystem does  not introduce a negative effect in the overall write latency and to cache usage. Chapter 9. Product integration  369