Bug 1348928 - Seeing a Crash at "librbd/operation/Request.cc: 92: FAILED assert(m_op_tid != 0)", while creating snapshot on Slave Node
Summary: Seeing a Crash at "librbd/operation/Request.cc: 92: FAILED assert(m_op_tid !=...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: RBD
Version: 2.0
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: rc
: 2.1
Assignee: Jason Dillaman
QA Contact: Rachana Patel
Bara Ancincova
URL:
Whiteboard:
Depends On:
Blocks: 1322504 1383917
TreeView+ depends on / blocked
 
Reported: 2016-06-22 10:43 UTC by Tanay Ganguly
Modified: 2017-07-30 15:35 UTC (History)
8 users (show)

Fixed In Version: RHEL: ceph-10.2.3-2.el7cp Ubuntu: ceph_10.2.3-3redhat1xenial
Doc Type: Bug Fix
Doc Text:
.Certain maintenance image operations are no longer incorrectly allowed on non-primary images With RADOS Block Device (RBD) mirroring enabled, non-primary images are expected to be read-only. Under certain conditions, the `rbd` command did not properly restrict `rbd` maintenance operations against non-primary images. The affected operations included: * updating snapshots * resizing images * renaming and creating clones using the non-primary image as the parent With this update, these operations are disallowed on non-primary images as expected.
Clone Of:
Environment:
Last Closed: 2016-11-22 19:26:49 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 16411 0 None None None 2016-08-10 18:42:13 UTC
Red Hat Product Errata RHSA-2016:2815 0 normal SHIPPED_LIVE Moderate: Red Hat Ceph Storage security, bug fix, and enhancement update 2017-03-22 02:06:33 UTC

Description Tanay Ganguly 2016-06-22 10:43:29 UTC
Description of problem:
Observed a Crash while Parent and Clone image are getting synced on the Slave Node. The mirror daemon crashed and again got restarted.

Version-Release number of selected component (if applicable):
10.2.2-5.el7cp.x86_64

How reproducible:
Once

Steps to Reproduce:
1.Executed the attached script.
   The Script does:
   Create Image with Journal enabled, take Snap, Protect Snap, Clone it with Journal enabled, unprotect snap,bench write on Clone, bench write on parent image.

Actual results:
Passed 4 iteration, failed in 5th Iteration (PFA, Script)

Expected results:
No Crash and Clone should sync completely.

Additional info:

Note: There was another sync on a different image named: bigimage1 (100GB) with complete data on it was also going on.

Following list gives the % synchronization complete on Slave Node at the time of Crash:

bigimage1 -- 1ebacfa8-fa2b-4c0a-8d38-56cbbee90507  COPY_OBJECT 70%   
liver5    -- ef4e2d9e-5d1c-4a58-87cf-edb46f43f242  COPY_OBJECT 72%
liverClone_new5 -- f40b86df-236c-4e63-b30d-24570a66ce79	COPY_OBJECT 44%

Comment 11 Jason Dillaman 2016-08-10 18:42:13 UTC
Upstream pull request: https://github.com/ceph/ceph/pull/9867

Comment 17 Rachana Patel 2016-10-28 01:29:06 UTC
verified with 10.2.3-10.el7cp.x86_64
working as expected hence moving to verified

Comment 21 errata-xmlrpc 2016-11-22 19:26:49 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://rhn.redhat.com/errata/RHSA-2016-2815.html


Note You need to log in before you can comment on or make changes to this bug.