Project

General

Profile

Bug #1197

osd: make inconsistent state durable

Added by Greg Farnum almost 13 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OSD
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

I'm pretty sure that if we ever get an inconsistent PG, that knowledge needs to be in permanent storage so that we don't end up in a situation where the map updates and we replicate based on one version of the data (which could be wrong) and remove the other version of it.

History

#1 Updated by Sage Weil over 12 years ago

  • Subject changed from Inconsistent state should not be transient to osd: make inconsistent state durable
  • Target version set to v0.37

If we mark the pg inconsistent on disk, what does that actually mean? Is it just a 'tainted' flag that propagates to anybody we share our pg::info with? Does it prevent recovery from proceeding?

Currently, scrub only starts once recovery completes.. we don't even consider PGs that are active but not clean.

#2 Updated by Sage Weil over 12 years ago

  • Target version deleted (v0.37)
  • translation missing: en.field_position set to 28

#3 Updated by Greg Farnum over 12 years ago

I don't remember exactly what prompted this bug. I think the issue was that somebody had a PG in an inconsistent state (because it didn't match between the OSDs with data), but then all the OSDs storing the PG went down and one came back up, and the PG went to active+clean after replicating. (Is that actually possible?)

So the concern was that if the inconsistency isn't written to durable storage, then in some situations it is possible to erroneously recover from that without actually resolving the inconsistency.

#4 Updated by Sage Weil about 11 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF