>
> Or, just reassign one existing OSD to the new class.
>
> >> Note that testing this rule with crushtool won't work here since the
> >> fake OSD isn't assigned to a hosts.
>
> > But what's the point in having a rule without the corresponding
> > devices? You won't be able to create a pool with
Or, just reassign one existing OSD to the new class.
>> Note that testing this rule with crushtool won't work here since the
>> fake OSD isn't assigned to a hosts.
> But what's the point in having a rule without the corresponding
> devices? You won't be able to create a pool with that rule anywa
Andre,
see responses inline.
Zitat von Andre Tann :
Ahoi Eugen,
Am 29.11.24 um 11:31 schrieb Eugen Block:
step set_chooseleaf_tries 5 -> stick to defaults, usually works
(number of max attempts to find suitable OSDs)
Why do we need more than one attempt to find an OSD? Why is the
resul
Ahoi Eugen,
Am 29.11.24 um 11:31 schrieb Eugen Block:
step set_chooseleaf_tries 5 -> stick to defaults, usually works (number
of max attempts to find suitable OSDs)
Why do we need more than one attempt to find an OSD? Why is the result
different if we walk through a rule more than once?
s
Which questions do you have? When I first started to deal with crush
rules I was overwhelmed, but with a bit of practice and trial & error
you're going to figure it out.
Maybe this helps a bit (inline comments):
id 6 -> self explanatory
type erasure -> self explanatory
step set_chooseleaf_
Hi yall,
Am 29.11.24 um 08:51 schrieb Eugen Block:
rule testrule {
id 6
type erasure
step set_chooseleaf_tries 5
step set_choose_tries 100
step take default class test
step chooseleaf indep 0 type host
step emit
}
Does anyone know
I know a bit the work-arounds for manually editing the crush map. I just think
this is not the best way to get acquainted to with a new ceph cluster. I would
make these hdd,nvme,ssd classes available directly.
> You could decompile the crushmap, add a dummy OSD (with a non-existing
> ID) with y
You could decompile the crushmap, add a dummy OSD (with a non-existing
ID) with your new device class and add a rule, then compile it and
inject. Here's an excerpt from a lab cluster with 4 OSDs (0..3),
adding a fifth non-existing:
device 4 osd.4 class test
rule testrule {
id 6
