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. -Sam 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). > > This allows us to cut out some of the other cases from PG and clarify > the in-memory state. > -Sam -- 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
