On Tue, 4 Apr 2017, Sage Weil wrote:
First question: Can we get away with returning osd_state.size()?
Nope!
Ok, that settles that! :-) Thanks!
Second, should the cached/memoized member variables set as a side-effect of
calc_num_osds() /ever/ be trusted if we don't call the method first?
Nope! We're careful to call it after decode() and apply_incremental(),
which are basically the only two paths that modify OSDMap.
Thanks, good to know!
Perhaps a method basically doing this would be useful, along these lines?
[...]
Maybe! Since osd_state is a vector its all very fast. Not sure that we
are bulding a set<int> of up or down often enough to justify
prebuilding it. (It also consumes memory, and on big clusters
we have lots of big OSDMaps in a cache that can't consume too much
memory.)
Yes, it would definitely use quite a bit of extra memory, at least the
size of the osd_state over again since we're making a copy. Maybe the only
way that would make sense would be to track them seperately from "go", but
then all the code touching osd_state would have to get more complicated.
I'm just poking around in mon's status reporting, so it makes sense to to
keep it local. Thanks!
WRT my other email, I'm indeed looking in a weird branch-- confusion
unconfusifificated!
Appreciatively,
-Jesse
--
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
