Project

General

Profile

Bug #90

mds: don't sync log on every clientreplay request

Added by Sage Weil over 8 years ago. Updated 7 months ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Performance/Resource Usage
Target version:
Start date:
05/03/2010
Due date:
% Done:

0%

Estimated time:
5.00 h
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:

History

#1 Updated by Sage Weil over 8 years ago

  • Target version set to 12

#2 Updated by Sage Weil about 8 years ago

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

#3 Updated by Sage Weil about 8 years ago

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

#4 Updated by Sage Weil over 7 years ago

  • Target version changed from 12 to 19

#5 Updated by Sage Weil over 7 years ago

  • Target version deleted (19)

#6 Updated by Sage Weil over 7 years ago

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

#7 Updated by Sage Weil about 6 years ago

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

#8 Updated by Sage Weil about 6 years ago

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

#9 Updated by Greg Farnum over 2 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 over 2 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 over 2 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 over 2 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 2 years ago

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

#15 Updated by Patrick Donnelly 7 months 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

Also available in: Atom PDF