On 10/06/2016, Sage Weil wrote: > The messengers aren't tied to CephContext, so I don't think this changes I'd thought each Messenger had a CephContext of its own and you'd want it to line up with that of the person calling it if you're interested in making sure logs go in the wrong places > things in that regard. I'm guessing we'll end up with something where > each entity has a thing that implements the Messenger interface but many > of those are sharing all their resources behind the scenes (thread pools, > multiplexing their connections, etc.). We'll have to figure out how the > config options related to messenger itself are handled, but I think that > oddity needs to be done explicitly anyway. We wouldn't for instance, want > to assume that all clusters in the same process must share the same > messenger options. (Maybe we invent an entity that governs the shared > resources (process.NNN) and somehow direct config options/admin socket > commands/whatever toward that? Who knows.) That's also true, you can replumb things a fair bit. > Is it pushed somewhere? Maybe much of the pain is related to the clock > thing... https://github.com/adamemerson/ceph/tree/wip-g_ceph_context-exterminate There's more to be done on it, but that's what's there. The Clock thing might help some, but the logging does seem to kill us. It ended up becoming much more of a time sink than I expected it to so even if we do end up going that route I need to do other things before I put much more work into it. (I'm going to look at that reweighting bug for one thing.) -- Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US IRC: Aemerson@{RedHat, OFTC, Freenode} 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
