Correct, except it doesn't have to be a specific host or a specific
OSD. What matters here is whether the client is idle. As soon as the
client is woken up and sends a request to _any_ OSD, it receives a new
osdmap and applies it, possibly emitting those dmesg entries.
Thanks for the clarification!
Zitat von Ilya Dryomov <idryo...@gmail.com>:
On Thu, Aug 30, 2018 at 1:04 PM Eugen Block <ebl...@nde.ag> wrote:
Hi again,
we still didn't figure out the reason for the flapping, but I wanted
to get back on the dmesg entries.
They just reflect what happened in the past, they're no indicator to
predict anything.
The kernel client is just that, a client. Almost by definition,
everything it sees has already happened.
For example, when I changed the primary-affinity of OSD.24 last week,
one of the clients realized that only today, 4 days later. If the
clients don't have to communicate with the respective host/osd in the
meantime, they log those events on the next reconnect.
Correct, except it doesn't have to be a specific host or a specific
OSD. What matters here is whether the client is idle. As soon as the
client is woken up and sends a request to _any_ OSD, it receives a new
osdmap and applies it, possibly emitting those dmesg entries.
Thanks,
Ilya
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
