]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
src/osd/PG.cc: remove redundant call to trim_log() 23354/head
authorNeha Ojha <nojha@redhat.com>
Tue, 31 Jul 2018 00:09:51 +0000 (17:09 -0700)
committerNeha Ojha <nojha@redhat.com>
Tue, 31 Jul 2018 18:43:02 +0000 (11:43 -0700)
commit283b0bde4a52128c1590afe8e5011b266a2e334b
tree49743265807e161cf1c2303fabf714e2ac3c6d73
parenta8b39ccc2c1845c99b10f26ed320156fc9b338c8
src/osd/PG.cc: remove redundant call to trim_log()

This change is motived by the failure tracked in
https://tracker.ceph.com/issues/25198. The failure highlights a case, when a
call to trim_log() after the PG has recovered, races with the previous op,
on a replica OSD. Since the previous operation has not completed, the
last_complete value for that OSD is not valid, when we try to trim the
log. It is also worth noting that the race is due to MOSDPGTrim going through
the strict queue as a peering message vs regular ops going through the
non-strict queue.

During the investigation of this bug, we noticed that, with
https://tracker.ceph.com/issues/23979, we allow pg log trimming to
happen on the primary and replicas, whenever we cross the upper bound of
the pg log. This also ensures that pg log trimming happens while processing
any new op.

Therefore, the function trim_log(), which earlier served the purpose of
trimming logs on the primary and replicas, just before the PG went into
the Recovered state, is no more required. This acted like a last line of
defense to trim logs, when we did not need the logs any more. But, this call
seems redundant now, because, we are limiting the pg log length at all times.

Signed-off-by: Neha Ojha <nojha@redhat.com>
src/osd/PG.cc
src/osd/PG.h