Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mon/OSDMonitor: properly set last_force_op_resend in stretch mode #45744

Merged
merged 1 commit into from
Apr 11, 2022

Conversation

idryomov
Copy link
Contributor

@idryomov idryomov commented Apr 1, 2022

Setting last_force_op_resend but not last_force_op_resend_prenautilus
and last_force_op_resend_preluminous doesn't make sense. The reverse,
such as

last_force_op_resend = 0
last_force_op_resend_prenautilus = 0
last_force_op_resend_preluminous = 20

or

last_force_op_resend = 0
last_force_op_resend_prenautilus = 40
last_force_op_resend_preluminous = 40

is valid in PG split/merge cases (and is the reason prenautilus and
preluminous fields actually exist and aren't just encoding artifacts),
but, if last_force_op_resend is set, both prenautilus and preluminous
fields should really be set to the same value. Otherwise it basically
amounts to "nautilus+ clients need to resend in-flight ops on stretch
mode transitions but pre-nautilus clients don't" which is bogus as it
leaves pre-nautilus clients exposed to the nastiness that necessitated
employing the force resend hammer in the first place in commit
97fbd19 ("osd: mon: account for stretch bucket configs/changes
when detecting intervals").

Fixes: https://tracker.ceph.com/issues/55158
Signed-off-by: Ilya Dryomov idryomov@gmail.com

Checklist

  • Tracker (select at least one)
    • References tracker ticket
    • Very recent bug; references commit where it was introduced
    • New feature (ticket optional)
    • Doc update (no ticket needed)
    • Code cleanup (no ticket needed)
  • Component impact
    • Affects Dashboard, opened tracker ticket
    • Affects Orchestrator, opened tracker ticket
    • No impact that needs to be tracked
  • Documentation (select at least one)
    • Updates relevant documentation
    • No doc update is appropriate
  • Tests (select at least one)
Show available Jenkins commands
  • jenkins retest this please
  • jenkins test classic perf
  • jenkins test crimson perf
  • jenkins test signed
  • jenkins test make check
  • jenkins test make check arm64
  • jenkins test submodules
  • jenkins test dashboard
  • jenkins test dashboard cephadm
  • jenkins test api
  • jenkins test docs
  • jenkins render docs
  • jenkins test ceph-volume all
  • jenkins test ceph-volume tox
  • jenkins test windows

Setting last_force_op_resend but not last_force_op_resend_prenautilus
and last_force_op_resend_preluminous doesn't make sense.  The reverse,
such as

  last_force_op_resend = 0
  last_force_op_resend_prenautilus = 0
  last_force_op_resend_preluminous = 20

or

  last_force_op_resend = 0
  last_force_op_resend_prenautilus = 40
  last_force_op_resend_preluminous = 40

is valid in PG split/merge cases (and is the reason prenautilus and
preluminous fields actually exist and aren't just encoding artifacts),
but, if last_force_op_resend is set, both prenautilus and preluminous
fields should really be set to the same value.  Otherwise it basically
amounts to "nautilus+ clients need to resend in-flight ops on stretch
mode transitions but pre-nautilus clients don't" which is bogus as it
leaves pre-nautilus clients exposed to the nastiness that necessitated
employing the force resend hammer in the first place in commit
97fbd19 ("osd: mon: account for stretch bucket configs/changes
when detecting intervals").

Fixes: https://tracker.ceph.com/issues/55158
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Copy link
Member

@gregsfortytwo gregsfortytwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eek! LGTM

I verified there are no other raw uses of last_force_op_resend in the OSDMonitor (and gripping the rest of the repo looks okay, though would take longer to audit).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants