On Fri, 9 Dec 2016, Samuel Just wrote: > In particular, we don't need PG::generate_past_intervals duplicating > the logic in build_past_intervals_parallel since constructed PG > objects only ever need to maintain a consistent past_intervals > structure, never build it from scratch. Sounds good to me. My main question is: > On Fri, Dec 9, 2016 at 11:59 AM, Samuel Just <sjust@xxxxxxxxxx> wrote: > > There's code for dealing with some odd past_intervals configurations > > including doesn't go back far enough and doesn't go forward far > > enough. I *think* we can simplify this as follows: > > 1) Once the PG object is constructed and in memory, past_intervals > > extends from history.last_epoch_started to the PG's current map > > 2) On disk, either 1) is true or the set is empty (after an import) > > > > On boot, the OSD generates past_intervals in parallel for any PGs > > without them (and perhaps verifies 1) for the rest). On receipt of a > > Notify creating a PG, the OSD generates the past_intervals structure > > before instantiating the PG using the same process as on boot -- > > starting with the included past_intervals if present (may not extend > > to the current map, and so may need to be extended). When does this actually happen? If PGs are always in state 1, can we instead ensure that PG notify will always include past_intervals and that a received notify will never require us to go off do the (slow) work of loading up old maps to generate old intervals? Then, we can focus our efforts on make the past_intervals representation compact (e.g., by discarding redundant intervals)... sage -- 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
