crushtool cannot always re-encode a crushmap that it's created
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 , 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 Updated by Sage Weil over 8 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.