Re: OSDMap / osd_state questions

[Jesse Williamson <jwilliamson@suse.de>]

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