Description of problem:
Consider a cluster with device all HDDs.
- Initially the ruleset "test" doesn't have a device class associated with it
rule test {
id 2
type replicated
min_size 1
max_size 10
step take default =========> hdd device class missing
step chooseleaf firstn 0 type host
step emit
}
- Edited the crushmap and added the device class
rule test {
id 2
type replicated
min_size 1
max_size 10
step take default class hdd =========> hdd device class present
step chooseleaf firstn 0 type host
step emit
}
After injecting the new crush map, we noticed some data movement. Ideally there shouldn't be any data movement as there is no change in the underlying osd disks types.
Is this expected behaviour? If yes,is there any workaround to prevent it as it causes large data movement?
Version-Release number of selected component (if applicable):
3.1
How reproducible:
Always
Description of problem: Consider a cluster with device all HDDs. - Initially the ruleset "test" doesn't have a device class associated with it rule test { id 2 type replicated min_size 1 max_size 10 step take default =========> hdd device class missing step chooseleaf firstn 0 type host step emit } - Edited the crushmap and added the device class rule test { id 2 type replicated min_size 1 max_size 10 step take default class hdd =========> hdd device class present step chooseleaf firstn 0 type host step emit } After injecting the new crush map, we noticed some data movement. Ideally there shouldn't be any data movement as there is no change in the underlying osd disks types. Is this expected behaviour? If yes,is there any workaround to prevent it as it causes large data movement? Version-Release number of selected component (if applicable): 3.1 How reproducible: Always