Bug 1578509

Summary:	entries_behind_master metric output but "rbd mirror image status " never reduces to zero.
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	Bob Emerson <roemerso>
Component:	RBD-Mirror	Assignee:	Jason Dillaman <jdillama>
Status:	CLOSED ERRATA	QA Contact:	Vasishta <vashastr>
Severity:	medium	Docs Contact:	Erin Donnelly <edonnell>
Priority:	medium
Version:	3.0	CC:	ceph-eng-bugs, ceph-qe-bugs, edonnell, hgurav, jdillama, mamccoma, roemerso, vashastr, vumrao
Target Milestone:	z4
Target Release:	3.0
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	ceph-12.2.4-24.el7cp	Doc Type:	Bug Fix
Doc Text:	Previously, the "entries_behind_master" metric output from the "rbd mirror image status" CLI tool did not always reduce to zero under synthetic workloads. This metric would only be updated after 32 write operations, or after an I/O flush was requested. This could cause a false alarm that there is an issue with RBD mirroring replications even though it is properly functioning. With this update, the metric is now updated periodically without the need for an explicit I/O flush in the workload.	Story Points:	---
Clone Of:
Clones:	1585192 (view as bug list)		Environment:
Last Closed:	2018-07-11 18:11:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1585192

Description Bob Emerson 2018-05-15 18:14:28 UTC

Description of problem:

Customer is running into the following upstream issue:

Ref upstream bug: https://tracker.ceph.com/issues/23457

entries_behind_master metric output but "rbd mirror image status " never reduces to zero.



Version-Release number of selected component (if applicable):

12.2.1-40.el7cp


How reproducible:


Customer can reproduce on demand

Comment 3 Bob Emerson 2018-05-15 18:17:12 UTC

Customer would like to know when this will be addressed in the downstream version.

Comment 4 Jason Dillaman 2018-05-16 23:04:32 UTC

It hasn't been fixed upstream yet since it has always been deemed as a low priority. The commit position (entries behind master is derived from this) is updated every 32 IOs or after each flush request. Was this from a synthetic workload that is just writing and never flushing?

Comment 16 Vasishta 2018-06-22 14:38:17 UTC

Working fine with 12.2.4-27

Moving to VERIFIED state, please let me know if there are any concerns.

Regards,
Vasishta Shatsry
AQE, Ceph

Comment 18 errata-xmlrpc 2018-07-11 18:11:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2177