From 9af64b8752ec0a3504305df74e8ab30372b81aca Mon Sep 17 00:00:00 2001 From: Brad Hubbard Date: Wed, 4 Jan 2017 15:10:35 +1000 Subject: [PATCH] osd/osd_types: Move comment to more relevant position The PriorSet constructor does not reference up_thru at all so the comment makes more sense in pg_interval_t::check_new_interval. Signed-off-by: Brad Hubbard --- src/osd/PG.cc | 42 ------------------------------------------ src/osd/osd_types.cc | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 42 deletions(-) diff --git a/src/osd/PG.cc b/src/osd/PG.cc index 9b49fe84dcb..97e43f3b2ce 100644 --- a/src/osd/PG.cc +++ b/src/osd/PG.cc @@ -8030,48 +8030,6 @@ PG::PriorSet::PriorSet(CephContext* cct, const PG *debug_pg) : cct(cct), ec_pool(ec_pool), pg_down(false), pcontdec(c) { - /* - * We have to be careful to gracefully deal with situations like - * so. Say we have a power outage or something that takes out both - * OSDs, but the monitor doesn't mark them down in the same epoch. - * The history may look like - * - * 1: A B - * 2: B - * 3: let's say B dies for good, too (say, from the power spike) - * 4: A - * - * which makes it look like B may have applied updates to the PG - * that we need in order to proceed. This sucks... - * - * To minimize the risk of this happening, we CANNOT go active if - * _any_ OSDs in the prior set are down until we send an MOSDAlive - * to the monitor such that the OSDMap sets osd_up_thru to an epoch. - * Then, we have something like - * - * 1: A B - * 2: B up_thru[B]=0 - * 3: - * 4: A - * - * -> we can ignore B, bc it couldn't have gone active (alive_thru - * still 0). - * - * or, - * - * 1: A B - * 2: B up_thru[B]=0 - * 3: B up_thru[B]=2 - * 4: - * 5: A - * - * -> we must wait for B, bc it was alive through 2, and could have - * written to the pg. - * - * If B is really dead, then an administrator will need to manually - * intervene by marking the OSD as "lost." - */ - // Include current acting and up nodes... not because they may // contain old data (this interval hasn't gone active, obviously), // but because we want their pg_info to inform choose_acting(), and diff --git a/src/osd/osd_types.cc b/src/osd/osd_types.cc index 3780d73b605..be9a4d5c860 100644 --- a/src/osd/osd_types.cc +++ b/src/osd/osd_types.cc @@ -3099,6 +3099,47 @@ bool pg_interval_t::check_new_interval( map *past_intervals, std::ostream *out) { + /* + * We have to be careful to gracefully deal with situations like + * so. Say we have a power outage or something that takes out both + * OSDs, but the monitor doesn't mark them down in the same epoch. + * The history may look like + * + * 1: A B + * 2: B + * 3: let's say B dies for good, too (say, from the power spike) + * 4: A + * + * which makes it look like B may have applied updates to the PG + * that we need in order to proceed. This sucks... + * + * To minimize the risk of this happening, we CANNOT go active if + * _any_ OSDs in the prior set are down until we send an MOSDAlive + * to the monitor such that the OSDMap sets osd_up_thru to an epoch. + * Then, we have something like + * + * 1: A B + * 2: B up_thru[B]=0 + * 3: + * 4: A + * + * -> we can ignore B, bc it couldn't have gone active (up_thru still 0). + * + * or, + * + * 1: A B + * 2: B up_thru[B]=0 + * 3: B up_thru[B]=2 + * 4: + * 5: A + * + * -> we must wait for B, bc it was alive through 2, and could have + * written to the pg. + * + * If B is really dead, then an administrator will need to manually + * intervene by marking the OSD as "lost." + */ + // remember past interval // NOTE: a change in the up set primary triggers an interval // change, even though the interval members in the pg_interval_t