osd: ScrubMap::object::get_object_info_t helper

[ghost]

Encapsulate decoding of attrs[OI_ATTR] in a helper and return on error
when OI_ATTR is not found. PG::repair_object uses the helper, logs an
error if it fails and return immediately.

http://tracker.ceph.com/issues/8345 Fixes: #8345

Signed-off-by: Loic Dachary loic@dachary.org

[ghost]

@dzafman it only partially implements what is described in http://tracker.ceph.com/issues/8345 . The PG::repair_object callers are also void functions and I'm not sure how the return value of PG::repair_object could be used if there is an error. Hints would be appreciated :-)

[athanatos]

This is probably going to be a bit more involved. If we are missing the oi attr, either we chose the wrong set of attrs as authoritative or none of the copies have the attr. In the former case, we want scrub to choose one with the oi_attr over one without it. In the latter case, I think the correct repair action is probably to delete the object. We should probably put this one off for the moment.

[ghost]

PGBackend::be_select_auth_object will not overlook a shard/copy without a valid OI_ATTR https://github.com/ceph/ceph/blob/master/src/osd/PGBackend.cc#L461 . If none of the shards/copies have a valid OI_ATTR it will select the first one ( https://github.com/ceph/ceph/blob/master/src/osd/PGBackend.cc#L442 ).

repair_object may get an object with no OI_ATTR or an invalid OI_ATTR. Should be_select_auth_object clear OI_ATTR if it is found invalid to facilitate error handling when repair_object is about to use it ? Or should it return an empty auth list to the caller when no shard/copy with a valid OI_ATTR, which would require a different logic in the caller ?

[ghost]

Based on the discussion we had today during the standup, my understanding is that the resolution of this problem should be delayed for now. The tracker has a link to this pull request for when it is reactivated.