Project

General

Profile

Bug #22945

[journal] allocating a new tag after acquiring the lock should use on-disk committed position

Added by Jason Dillaman over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Target version:
-
Start date:
02/07/2018
Due date:
% Done:

0%

Source:
Tags:
Backport:
luminous,jewel
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

Description

Related to issue #22932

If a client crashes before persisting its commit position and recovers, it will replay the on-disk events, advance the commit position, and allocate a new tag for future events. However, the tag predecessor is constructed using the original cached commit position and not the current commit position after replay.


Related issues

Copied to rbd - Backport #23011: luminous: [journal] allocating a new tag after acquiring the lock should use on-disk committed position Resolved
Copied to rbd - Backport #23012: jewel: [journal] allocating a new tag after acquiring the lock should use on-disk committed position Resolved

History

#1 Updated by Jason Dillaman over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Jason Dillaman

#2 Updated by Jason Dillaman over 1 year ago

  • Status changed from In Progress to Need Review

#3 Updated by Mykola Golub over 1 year ago

  • Status changed from Need Review to Pending Backport

#4 Updated by Nathan Cutler over 1 year ago

  • Copied to Backport #23011: luminous: [journal] allocating a new tag after acquiring the lock should use on-disk committed position added

#5 Updated by Nathan Cutler over 1 year ago

  • Copied to Backport #23012: jewel: [journal] allocating a new tag after acquiring the lock should use on-disk committed position added

#6 Updated by Nathan Cutler about 1 year ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF