Project

General

Profile

Bug #4829

client: handling part of MClientForward incorrectly?

Added by Greg Farnum over 6 years ago. Updated 9 months ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Target version:
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Client
Labels (FS):
multimds
Pull request ID:
Crash signature:

Description

(In reference to a backwards check for is_replay when doing encode_cap_releases())

Greg
isn't that backwards?
only encoding the releases if we got an unsafe reply?

Sage Weil
argh
btw i suspect this is also wrong wrt forwards

Greg
backwards logic?
I haven't seen your patches for it yet

Sage Weil
fixed that
i mean, i think we only want to do this the first attempt for the request, not each time we forward.
but that needs a careful look at handling for the MClientForward stuff
like, that swap() obviously will only work the first time around.. but the other encode_cap_releases() will do it each tie
time
so at the very least its slightly wrong

History

#1 Updated by Sage Weil over 6 years ago

  • Priority changed from Normal to High

#2 Updated by Greg Farnum almost 6 years ago

  • Priority changed from High to Low

Demoting due to uclient and multi-mds.

#3 Updated by Greg Farnum over 3 years ago

  • Category changed from 46 to 90
  • Component(FS) Client added

#4 Updated by John Spray about 3 years ago

  • Priority changed from Low to High
  • Target version set to v12.0.0

Targeting for Luminous to investigate and either fix or close this.

#5 Updated by Zheng Yan almost 3 years ago

I can't see why we shouldn't encode cap releases after receiving MClientForward. The old releases is for the old MDS, the new releases is for the new target mds

#6 Updated by Zheng Yan about 2 years ago

  • Status changed from New to Closed

#7 Updated by Patrick Donnelly 9 months ago

  • Category deleted (90)
  • Labels (FS) multimds added

Also available in: Atom PDF