]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
src/osd/PG.cc: remove redundant call to trim_log()
authorNeha Ojha <nojha@redhat.com>
Tue, 31 Jul 2018 00:09:51 +0000 (17:09 -0700)
committerNeha Ojha <nojha@redhat.com>
Fri, 18 Jan 2019 19:06:13 +0000 (14:06 -0500)
commitc2e58cbfd22ce57f98f90a374110af07d3472ca7
tree98da08da4e8ea9a719fa327ee2df08fed2b66b99
parentfcc91fdc1a7db3c43ad498a5332c9eb2ef9128b7
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>
(cherry picked from commit 283b0bde4a52128c1590afe8e5011b266a2e334b)

Conflicts:
src/osd/PG.cc: We do not need the trim_log() call any longer,
        due to the explanation provided in the commit message.
src/osd/PG.cc
src/osd/PG.h