Consider the type of I/O and frequency of update before you create the volumes that you want to use in FlashCopy mappings.
FlashCopy operations complete in direct proportion to the performance of the source and target disks. If you have a fast source disk and slow target disk, the performance of the source disk is reduced because it must wait for the write operation to occur at the target before it can write to the source.
The FlashCopy implementation that is supported on the system copies at least 256 K every time a write is made to the source. This implementation means that any write involves at minimum a read of 256 K from the source, write of the same 256 K at the target, and a write of the original change at the target. Therefore, when an application completes small 4 K writes, this size is converted into 256 K.
Because of this implementation, consider the type of I/O that your application completes during a FlashCopy operation. Ensure that you do not overload the storage. The calculations contain a heavy weighting when the FlashCopy feature is active. The weighting depends on the type of I/O that is completed. Random writes can have a much higher impact than sequential writes. For example, the sequential write would copy the entire 256 K.
You can spread the FlashCopy source volumes and the FlashCopy target volumes between as many storage pools as possible. This configuration limits the potential bottle-necking of a single storage system (assuming that the storage pools contain MDisks from different storage systems). However, this configuration can still result in potential bottlenecks if you want to maintain all your target volumes on a single storage system. You must ensure that you add the appropriate weighting to your calculations.