Project

General

Profile

Bug #558

crushtool cannot always re-encode a crushmap that it's created

Added by Ravi Pinjala over 13 years ago. Updated almost 7 years ago.

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

0%

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

Description

When a CRUSH text map is encoded, the buckets are read in such a way that they must be defined before they are referenced. For example, in [1], the hosts must be defined before the racks. Each entry also includes an ID number. When the CRUSH map is encoded and then decoded again, the entries are printed out in the order corresponding to their IDs, rather than the order they were originally in the text map.

However, since the order in the text map matters, this means that when non-sequential IDs are used, there are situations where crushtool can successfully encode a map, and later decode it successfully, but fails when you try to re-encoded the decoded result.

It's not at all clear what the IDs are used for; the only mention is a cryptic comment not to change them unnecessarily. It would be nice if they were implicit based on the order of buckets in the file; failing that, crushtool should at least warn when the IDs are non-sequential.

[1] http://ceph.newdream.net/wiki/Custom_data_placement_with_CRUSH#Example_crush_map

History

#1 Updated by Sage Weil over 13 years ago

  • Category set to 10
  • Assignee set to Colin McCabe
  • Target version set to v0.23

Either the compiler part just needs to be updated to allow forward bucket references, or the dumper needs to dump by traversing the hierarchy instead of walking the bucket list in order.

#2 Updated by Sage Weil over 13 years ago

  • Priority changed from Normal to Immediate

#3 Updated by Sage Weil over 13 years ago

  • Priority changed from Immediate to Normal

#4 Updated by Sage Weil over 13 years ago

  • Estimated time set to 3.00 h
  • Source set to 1

#5 Updated by Colin McCabe over 13 years ago

  • Status changed from New to Resolved

Fixed by commit:9b48725614a880cf1f4bcad0bba2ceefdc76c167

C.

#6 Updated by Greg Farnum almost 7 years ago

  • Project changed from Ceph to RADOS
  • Category deleted (10)
  • Target version deleted (v0.23)

Also available in: Atom PDF