FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10308/

• FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10308/

This was manually test. I'm not sure how to add a Hammer upgrade test which would leave stray temp objects in order to verify that they are cleaned up.

I think this is being caught by the existing tests, see http://tracker.ceph.com/issues/13381

I'll just check "q->hobj.get_pool() == -1" as the entire check and not use is_meta() because we don't want to break if is_meta() changes in the future. We are checking for an old release remnant at that point.

I was being paranoid not to confuse the is_pgmeta() object (possibly an older one) from the pool == -1 temporary objects from prior releases. So the name.empty() check is probably not be needed because if pool == -1 it will never also be an is_pgmeta() object.

  bool is_pgmeta() const {
    // make sure we are distinct from hobject_t(), which has pool INT64_MIN
    return hobj.pool >= 0 && hobj.oid.name.empty();
  }

hobject_t::is_meta() looks like this:

 bool is_meta() const {
    return pool == POOL_META;
  }

Is that last patch needed, now that the temp objects get cleaned up on startup?

@liewegas I think the reason for the last commit has changed. If we set the pool, then during scrubbing the FileStore::collection_list() as an example, doesn't waste cycles reading the temp collection only to have the list pruned by PGBackend::objects_list_range(() called by PG::build_scrub_map_chunk().

FileStore::collection_list():

  if (!c.is_temp() && !c.is_meta()) {
    if (cmp_bitwise(start, sep) < 0) { // bitwise vs nibble doesn't matter here
      dout(10) << __func__ << " first checking temp pool" << dendl;
      coll_t temp = c.get_temp();
      int r = collection_list(temp, start, end, sort_bitwise, max, ls, next);

@liewegas I changed the commit message on the last commit and removed the revert of PG::replica_scrub() change which set pool for scrubbing with hammer OSDs.

Ok, I think this'll work! And it fixes your original issue (the second commit does i guess), right?

@liewegas Yes, the second commit causes the old temp objects to be removed.