Make GMCV FC Mappings use their own dedicated 'chain', with no dependencies to other FC Mappings using the same Source Volumes.
GMCV establishes a FlashCopy Mapping from the source/production volume to the Change Volume (as well as a reverse FC Mapping). If/when I create additional FC Mappings using the same production volumes as the source, the GMCV FCMap utilizes the same "FlashCopy Dependency Chain" as any additional FC Mapping(s) in this Multiple Copy FlashCopy configuration. Since the GMCV cycles relatively frequently (as little as 5 minutes depending on your configured Cycle Time/RPO), it is almost always the newest FCMapping in the FC Dependency Chain. So every GMCV cycle, the changed grains from the GMCV FC Mapping must be 'Cleaned' off to the next newest FC Mapping in the Chain, before the GMCV FC Mapping can transition from a Stopping state to a Stopped state, and begin the next GMCV Cycle.
If the source volume experienced a high write change rate in the current cycle, this can take multiple HOURS utilizing the default '0' clean rate (Clean runs only when the GMCV FC Mapping is stopped, at the default 50/2MBps rate). And while that Cleaning is occurring, the effective RPO of the affected GMCV Consistency Group is lagging further and further, possibly to many hours. This presents potentially unusable DR copies, as you can frequently end up with some CG's at a few minutes RPO, and others (that are experiencing excessive Stopping times due to Cleaning of a volume with high Write Changes) at a few hours RPO. For an entire environment that is undergoing a disaster recovery to GMCV Remote Copy target volumes, restoring the environment to numerous Remote Copy CG's that are hours different Point-in-Time can result in unusable or very problematical application states.
This can be mitigated to some extent by manually setting a non-zero 'Clean Rate' for every single GMCV FC Mapping (or at least for the ones that experience frequent high write change rates). But that can be very cumbersome, since it will usually involve running CLI commands (GMCV FC Mapping Clean Rate not modifiable via GUI) for hundreds of volumes & FC Mappings (entire Prod environment, or constantly figuring out which individual volumes have high Write Change Rates), and since there is a need to make best attempts to monitor the impact that higher background cleaning rates have on Source/Production Volume performance.
Obviously, this is not an issue whatsoever if no other FlashCopies of your Source/Production Volumes are utilized. But as soon as even just one additional FC Mapping using the Prod volume as the Source is configured, this becomes an issue. So GMCV utilizing the same FC Mapping Dependency Chain as any other FC Mappings is problematical, and makes the utilization of FlashCopies for anything other than GMCV a questionable undertaking.
There is a trade-off here in that GMCV FC Mappings not being part of the default dependency chain would mean that TWO Copies on Writes would need to be performed by every Prod Volume Write. But the additional capacity utilized by that extra copy of changes, over one single GMCV Cycle period, would be relatively small (assuming hours-long Cycle period is not in place). And I would think that destaging the copied write from lower cache to two disk locations would not put any significant performance load or latency increase on the system versus destaging that write to only one disk location (especially on flash storage systems).
