Actions
Bug #4266
closedcrush placement from crushtool mismatches observed behavior for pools other than zero
Status:
Won't Fix
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:
0%
Source:
Development
Tags:
Backport:
Regression:
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
Because OSDs add the pool id to the pg number to form the x passed to crush_do_rule, whereas crushtool just gets an x range, the pg assignment to osd may seem to differ between the two.
I suppose documenting in the cmd line usage the fact that you have to add the pool id to the pg range when determining the x range you're interested in might suffice to address this mismatch, although it might be desirable if crushtool would take pool and pg counts rather than x.
Updated by Sage Weil about 11 years ago
- Status changed from New to Won't Fix
The --x is only coincidentally related to the second part of hte pgid (currently). If you want to map a specific pgid, use osdmaptool --test-map-pg. that will also then take the osd state (up/down/in/out) into consideration.. which crushtool does/can not.
Actions