I think this is a bug. Looking at the mon log when creating such a pool, it appears that it's parsing the crush_rule as an erasure-code profile and then selects the default rule 0 (default replicated_rule), resulting in the last parameter being used as "expected_num_objects" instead of "size": soc9-ceph:~ # ceph osd pool create temp7 4 replicated test-rep1 0 4 pool 'temp7' created entity='client.admin' cmd='[{"prefix": "osd pool create", "pool": "temp7", "pg_num": 4, "pool_type": "replicated", "erasure_code_profile": "test-rep1", "rule": "0", "expected_num_objects": 4}]': finished So I played around a bit, trying to find out which syntax would work. I currently only have one EC profile "default": soc9-ceph:~ # ceph osd erasure-code-profile ls default So let's try it like this: soc9-ceph:~ # ceph osd pool create temp7 4 replicated default test-rep1 0 4 Error EINVAL: error parsing integer value 'test-rep1': Expected option value to be integer, got 'test-rep1' But the log correctly shows all the parameters in the right place, although the pool is not created due to the above message: entity='client.admin' cmd=[{"prefix": "osd pool create", "pool": "temp7", "pg_num": 4, "pool_type": "replicated", "erasure_code_profile": "default", "rule": "test-rep1", "expected_num_objects": 0, "size": 4}]: dispatch And the help page also doesn't mention that the rule parameter is supposed to be an integer. So that's weird... This command results in the expected pool (using an integer for the rule and "test-rep1" as ec profile): soc9-ceph:~ # ceph osd pool create temp7 4 replicated test-rep1 1 0 4 pool 'temp7' created entity='client.admin' cmd='[{"prefix": "osd pool create", "pool": "temp7", "pg_num": 4, "pool_type": "replicated", "erasure_code_profile": "test-rep1", "rule": "1", "expected_num_objects": 0, "size": 4}]': finished If I use "default" for the ec profile, it (incorrectly) assumes it's a rule name: soc9-ceph:~ # ceph osd pool create temp8 4 replicated default 1 0 4 Error ENOENT: specified rule default doesn't exist Although the mon command is parsed as expected: entity='client.admin' cmd=[{"prefix": "osd pool create", "pool": "temp8", "pg_num": 4, "pool_type": "replicated", "erasure_code_profile": "default", "rule": "1", "expected_num_objects": 0, "size": 4}]: dispatch This is really a mess. I know it's a bit difficult to keep an overview here. I will create a tracker issue for this. Zitat von Eugen Block <eblock@nde.ag>:
Forgot to add that it's version 19.2.2 (also tried it on 19.2.0).
Zitat von Eugen Block <eblock@nde.ag>:
Hi,
without having checked the tracker, does anyone have an explanation why the size parameter is not applied when creating a pool via CLI? According to the help output for 'ceph osd pool create -h' you can specify expected_num_objects (btw. I don't understand what impact that has, all I could find was related to filestore OSDs and PG splitting) and then the size:
profile>] [<rule>] [<expected_num_objects:int>] [<size:int>] [<pg_num_min:int>] [<pg_num_max:
If I specify both parameters, the pool gets its default size according to osd_pool_default_size (this is a single node cluster, hence default size 2):
soc9-ceph:~ # ceph osd pool create temp5 4 replicated replicated_rule 0 4
pool 4 'temp5' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 4 pgp_num 4 autoscale_mode off last_change 260 flags hashpspool stripe_width 0 read_balance_score 1.00
I get the same result on a larger test cluster with multiple hosts. Of course I know that I could just set the size afterwards, but is the command broken? Has anyone looked into this?
Thanks! Eugen