Actions
Backport #16950
closedjewel: librbd/ExclusiveLock.cc: 197: FAILED assert(m_watch_handle != 0)
Release:
jewel
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Updated by Loïc Dachary over 7 years ago
- Copied from Bug #16923: librbd/ExclusiveLock.cc: 197: FAILED assert(m_watch_handle != 0) added
Updated by Loïc Dachary over 7 years ago
Updated by Loïc Dachary over 7 years ago
- Assignee set to Jason Dillaman
Here also there is a need to backport a commit which does not seem suitable for jewel because it refactors things https://github.com/ceph/ceph/pull/10574/commits/814c305ce8c35b5ce01d7e29a912d5ef3978754b . What do you think ?
Updated by Wes Dillingham over 7 years ago
Just adding a +1 to this backport as we are experiencing it in our 10.2.2 environment.
The errors are coinciding with our backup schedule, as we nightly take a sequence of snapshots (from a separate backup client) of each and every rbd device. While the snapshots succeed it causes our VMs to crash.
and we get the following in our qemu logs:
librbd/ExclusiveLock.cc: In function 'std::string librbd::ExclusiveLock<ImageCtxT>::encode_lock_cookie() const [with ImageCtxT = librbd::ImageCtx; std::string = std::basic_string<char>]' thread 7f6de0e68d00 time 2016-08-21 00:49:52.466515 librbd/ExclusiveLock.cc: 217: FAILED assert(m_watch_handle != 0) ceph version 10.2.2-1-g165f6a3 (165f6a3d17fb5e76ac9f6b91b5b9be95f8d665ae)
Updated by Loïc Dachary over 7 years ago
- Assignee deleted (
Jason Dillaman)
now that the commits responsible for the conflict were backported, it should be easier to deal with, scheduling it to be worked on by the next shift
Updated by Jason Dillaman over 7 years ago
- Status changed from New to In Progress
- Assignee set to Jason Dillaman
Updated by Loïc Dachary over 7 years ago
- Status changed from In Progress to Resolved
- Target version set to v10.2.3
Actions