Red Hat Bugzilla – Bug 1258953
Changing pg_num on a pool that uses a custom CRUSH ruleset, doesn't change the total PGs in the cluster.
Last modified: 2017-09-20 13:23:45 EDT
Increasing the PG number doesn't work for a pool created on a ruleset defined with an ID that is not consecutive to existing rulesets
1) Description of problem:
If a new ruleset is defined and it does not have consecutive numbering wrt to the existing rulesets, increasing the PG number later won't work.
2) Version-Release number of selected component (if applicable):
3) How reproducible:
4) Steps to Reproduce:
a) Create a new ruleset with an ID that is not consecutive to the previous/existing rulesets.
b) Create a pool with the new ruleset.
c) Try to increase the PG number
d) Even though this won't complain, the changed PG number won't take effect.
The work around is to change the ruleset number in the crush map, re-inject the crush map, and set the pool to the new ruleset.
5) Actual results:
The pg_num and pgp_num cannot be changed on a pool if the ruleset number is not consecutive to the existing ruleset numbers.
6) Expected results:
Setting a ruleset number which is not consecutive, shouldn't bring up this. A message at that time of compiling the crushmap pointing to the ruleset numbers should suffice. Or else, there shouldn't be such a restriction of ruleset ordering.
I'd like the following:
Ouptut from: ceph pg dump
The file from: ceph osd getmap -o <filename>
And the /var/log/ceph/ceph.log file.