Project

General

Profile

Actions

Bug #10171

closed

DBObjectMap: ghobject_t header key excludes hash for EC pools

Added by Sage Weil over 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
% Done:

0%

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

Description

diff --git a/src/os/DBObjectMap.cc b/src/os/DBObjectMap.cc
index c5a5b69..f834730 100644
--- a/src/os/DBObjectMap.cc
+++ b/src/os/DBObjectMap.cc
@@ -154,7 +154,7 @@ string DBObjectMap::ghobject_key(const ghobject_t &oid)
     t += snprintf(t, end - t, ".none");
   else
     t += snprintf(t, end - t, ".%llx", (long long unsigned)oid.hobj.pool);
-  snprintf(t, end - t, ".%.*X", (int)(sizeof(oid.hobj.hash)*2), oid.hobj.hash);
+  t += snprintf(t, end - t, ".%.*X", (int)(sizeof(oid.hobj.hash)*2), oid.hobj.hash);

   if (oid.generation != ghobject_t::NO_GEN ||
       oid.shard_id != shard_id_t::NO_SHARD) {

fixes the original bug. The problem is that for any EC object we dropped the ".xxxxxxxx" hash value.

The good news is we can disambiguate this from the gen, which is 64 bits instead of 32. The bad news is we need to transparently handle both... help!

Turned this up with the wip-pgmeta branch with EC pools: we crash almost immediately because we have an object with the same name ('') with different hash values, but they end up in the same key and we trip over the in_use asserts.

Actions #1

Updated by Sage Weil over 9 years ago

  • Assignee changed from Samuel Just to Sage Weil
Actions #2

Updated by Sage Weil over 9 years ago

  • Status changed from 12 to Fix Under Review
Actions #3

Updated by Sage Weil about 9 years ago

  • Status changed from Fix Under Review to Resolved
Actions

Also available in: Atom PDF