On 3/23/21 11:00 AM, Nico Schottelius wrote:
Stefan Kooman <stefan@bit.nl> writes:
OSDs from the wrong class (hdd). Does anyone have a hint on how to fix this?
Do you have: osd_class_update_on_start enabled?
So this one is a bit funky. It seems to be off, but the behaviour would indicate it isn't. Checking the typical configurations:
[10:38:53] black2.place6:~# ceph config-key get config/global/osd_class_update_on_start; echo "" obtained 'config/global/osd_class_update_on_start' false
[10:39:59] black2.place6:~# ceph-conf -D | grep osd_class_update_on_start osd_class_update_on_start = true
[10:47:24] black2.place6:~# grep osd_class_update_on_start /etc/ceph/ceph.conf
[10:52:59] black2.place6:~# ceph config dump | grep osd_class_update_on_start global advanced osd_class_update_on_start false [10:53:38] black2.place6:~#
So it looks like it's already disabled.
What does a "ceph daemon osd.$id config get osd_class_update_on_start" give on that host for an OSD that is running there? It depends on settings on logging of the OSD daemons, but in our case it was logged to the daemon log I believe (or syslog, dunno anymore).
I am not sure where ceph-conf reads the value true from, but I assume it's a builtin.
I was also searching for osd_class_update_on_start in the Internet and it seems there is no reference to it in the ceph documentation. Do you have any pointers to it?
Not anymore with new Ceph documentation. But the parameter is self explaining, it will try to put itself into the proper class at startup. Source code: src/common/options.cc Option("osd_class_update_on_start", Option::TYPE_BOOL, Option::LEVEL_ADVANCED) .set_default(true) .set_description("set OSD device class on startup"), Gr. Stefan