Description of problem: in mirror image status, each element needs to be consistent with each other Example - bytes_per_second and replay_state As per understanding, bytes_per_second refers to the speed at which sync is happening and replay_state is the status of sync replay_state should be idle only when sync is done, i,e bytes_per_second reaches zero Version-Release number of selected component (if applicable): 16.2.0-146.el8cp How reproducible: Have tried in 4.3, it was reproducible Steps to Reproduce: 1. Configure snapshot based mirroring 2. add some data into an image and take a mirror snapshot 3. observe mirror image status at secondary site Actual results: $ sudo rbd mirror image status two_way_rep_snapshot_image/image01 image01: global_id: 40118ceb-d5a1-4079-bfeb-89375e23e681 state: up+replaying description: replaying, {"bytes_per_second":244032232.73,"bytes_per_snapshot":2684354560.0,"local_snapshot_timestamp":1643123739,"remote_snapshot_timestamp":1643123739,"replay_state":"idle"} Expected results: bytes_per_second should be zero by the time reply state is reported as idle Additional info: Observed this for images of various sizes from 1G to 50G, snapshot sync and complete resync
Hi Vasishta, You might observe some delay because the stats actually get updated after it re-scans the image. Which is basically needed to calculate the average number of bytes got copied per snapshot. Hope this helps. Thanks, Sunny
Hi Sunny, Thanks for the insights on the slight delay in the update of bytes_per_second. Though I agree that the delay very small, I think it would be a nice thing if we can bring co-ordination between related stats if bytes_per_second is a metric that denotes the data being copied from the peer cluster. Regards, Vasishta