MV/A uses Snapview snapshot technology to ensure consistency at the DR location. For normal Snapview Snapshots, the RLP will continue to grow as long as there is a snapshot session. Only when a snapshot session is destroyed, the space consumed in the RLP for that session is released.  For Mirrorview/A, the use of the RLP is different from a snapshot. The RLP stores a bitmap in each RLP and that remains even with the MV/A session is fractured. But the bitmaps are very small and do not grow. The bitmap just tracks which blocks in the LUN have been modified at least once since the last MV/A update. COFW data is only created/tracked during an active update. When an update starts, MV/A checks the bitmap and creates a snapshot session for only the blocks that are marked for the update. Then during the update, any writes to a marked block create COFW data which is stored in the RLP. When the update completes successfully, the bitmap and COFW data are both cleared. If an update is unsuccessful and the session fractures, the bitmap remains, ready for another attempt, but the snapshot session is removed and the COFW data is cleared.  Technically there are two bitmaps per source LUN. One is used between updates to mark changes, and the other is used to mark new changes while the update is in progress. The bitmaps swap each time an update starts.  Compared to a full snapshot, MV/A creates less COFW data and has a lower performance impact on the source LUN.  I hope that makes sense.  Richard J Anderson
I want to know what RLP status is in PR site VNX after the mirror’s secondary image is fractured. Will it  be possible full since the data can not  transmit to the DR site?
will reversed lun pool be full after fractured in mirrorview/A