Bug 1258953 - Changing pg_num on a pool that uses a custom CRUSH ruleset, doesn't change the total PGs in the cluster. [NEEDINFO]
Changing pg_num on a pool that uses a custom CRUSH ruleset, doesn't change th...
Status: CLOSED WORKSFORME
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: RADOS (Show other bugs)
1.3.0
All Linux
medium Severity medium
: rc
: 1.3.4
Assigned To: Vimal Kumar
ceph-qe-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 11:13 EDT by Vimal Kumar
Modified: 2017-09-20 13:23 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-20 13:23:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sjust: needinfo? (vikumar)
sjust: needinfo? (vikumar)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1750353 None None None Never

  None (edit)
Description Vimal Kumar 2015-09-01 11:13:57 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):

RHCS1.2.3
ceph-0.80.9

3) How reproducible:

Always

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.
Comment 4 David Zafman 2015-11-03 13:34:34 EST
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.

Note You need to log in before you can comment on or make changes to this bug.