Fix #10519
closedReplace numerical value 0x7fffffff / MAX_UINT with CRUSH_ITEM_NONE in ceph pg dump
100%
Description
The numerical value representing CRUSH_ITEM_NONE confuses people : it looks like a bug. Having CRUSH_ITEM_NONE or another symbolic name would help figure out that it's because of a failed crush mapping.
Files
Updated by Loïc Dachary about 9 years ago
To reproduce this problem you can create a cluster with 2 OSDs and create an erasure coded pool using the default settings. There will not be enough OSDs for the PG of the erasure coded pool to be mapped and you will see this value (in decimal) with ceph pg dump.
It's great that you're working on this.
Updated by Loïc Dachary about 9 years ago
- Status changed from New to In Progress
Updated by Alyona Kiseleva about 9 years ago
I resolve it by replacing constant by string CRUSH_ITEM_NONE, like this:
$ ./ceph pg dump
pg_stat objects mip degr misp unf bytes log disklog state state_stamp v reported up up_primary acting acting_primary last_scrub scrub_stamp last_deep_scrub deep_scrub_stamp
3.8 0 0 0 0 0 0 0 0 active+undersized+degraded 2015-01-23 13:42:19.294764 0'0 11:6 [1,CRUSH_ITEM_NONE,0] 1 [1,CRUSH_ITEM_NONE,0] 1 0'0 2015-01-23 13:42:17.628127 0'0 2015-01-23 13:42:17.628127
Updated by Loïc Dachary about 9 years ago
- % Done changed from 0 to 70
It looks good :-) Would you mind proposing your modification via a pull request at https://github.com/ceph/ceph/pulls ?
Updated by Loïc Dachary about 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 70 to 100