Project

General

Profile

Bug #90

mds: don't sync log on every clientreplay request

Added by Sage Weil almost 14 years ago. Updated 15 days ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Performance/Resource Usage
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
mimic,luminous
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
MDS
Labels (FS):
task(easy)
Pull request ID:
Crash signature (v1):
Crash signature (v2):

History

#1 Updated by Sage Weil over 13 years ago

  • Target version set to 12

#2 Updated by Sage Weil over 13 years ago

  • Estimated time set to 5.00 h
  • Source set to 5

#3 Updated by Sage Weil over 13 years ago

  • translation missing: en.field_position deleted (303)
  • translation missing: en.field_position set to 302

#4 Updated by Sage Weil almost 13 years ago

  • Target version changed from 12 to 19

#5 Updated by Sage Weil over 12 years ago

  • Target version deleted (19)

#6 Updated by Sage Weil over 12 years ago

  • translation missing: en.field_position deleted (480)
  • translation missing: en.field_position set to 823

#7 Updated by Sage Weil over 11 years ago

  • Project changed from Ceph to CephFS
  • Category deleted (1)

#8 Updated by Sage Weil over 11 years ago

  • translation missing: en.field_position deleted (1276)
  • translation missing: en.field_position set to 581

#9 Updated by Greg Farnum almost 8 years ago

  • Category set to 47
  • Priority changed from Low to Normal

This'll probably kill us in a cluster of any size...?

#10 Updated by John Spray almost 8 years ago

Is this definitely still an issue? I'm not seeing a particular place in the code where we do something different with the mdlog while in clientreplay

#11 Updated by Greg Farnum almost 8 years ago

It might be fixed; we should check. But once upon a time (I think maybe still now?) then when in clientreplay set the flag that requests an immediate journal flush.

#13 Updated by Greg Farnum almost 8 years ago

Yeah. So, I think there was a reason for this. We definitely need to flush out any clientreplay requests before exiting clientreplay. But any ops in clientreplay shouldn't be dependent (except within a single-client stream, where we don't care), so our data guarantees should be met just by flushing once before we exit clientreplay. Right?

Or is there some other interaction we need to worry about?

#14 Updated by Greg Farnum over 7 years ago

  • Category changed from 47 to Performance/Resource Usage
  • Component(FS) Common/Protocol, MDS added

#15 Updated by Patrick Donnelly almost 6 years ago

  • Tracker changed from Feature to Bug
  • Priority changed from Normal to High
  • Target version set to v14.0.0
  • Source set to Development
  • Backport set to mimic,luminous
  • Regression set to No
  • Severity set to 3 - minor
  • Component(FS) deleted (Common/Protocol)
  • Labels (FS) task(easy) added

#16 Updated by Patrick Donnelly about 5 years ago

  • Target version changed from v14.0.0 to v15.0.0

#17 Updated by Patrick Donnelly about 5 years ago

  • Target version deleted (v15.0.0)

Also available in: Atom PDF