Async recovery peers usually have a relative complete
log history but may exist a lot of missing objects. Choosing them
as auth_log_shard and further as primary if current up_primary is
unrecoverable, say, could have a bigger chance to block client I/Os.
Among peers with identical new log history, we now consider those
who are now complete (having no missing objects) as the preferred
ones when determining auth_log_shard.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
continue;
}
+ if (!p->second.has_missing() && best->second.has_missing()) {
+ dout(10) << __func__ << " prefer osd." << p->first
+ << " because it is complete while best has missing"
+ << dendl;
+ best = p;
+ continue;
+ } else if (p->second.has_missing() && !best->second.has_missing()) {
+ dout(10) << __func__ << " skipping osd." << p->first
+ << " because it has missing while best is complete"
+ << dendl;
+ continue;
+ } else {
+ // both are complete or have missing
+ // fall through
+ }
+
// prefer current primary (usually the caller), all things being equal
if (p->first == pg_whoami) {
dout(10) << "calc_acting prefer osd." << p->first
bool is_empty() const { return last_update.version == 0; }
bool dne() const { return history.epoch_created == 0; }
+ bool has_missing() const { return last_complete != last_update; }
bool is_incomplete() const { return !last_backfill.is_max(); }
void encode(bufferlist& bl) const;