Project

General

Profile

Actions
Copy link

Bug #520

closed

mds: change ifile state mix->sync on (many) lookups?

Added by Sage Weil over 13 years ago. Updated over 11 years ago.

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

0%

Source:
Tags:
Backport:
Regression:
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

I'm seeing this on csyn --syn makefiles 1000 1 0


2010-10-26 19:33:20.911692 7f91ddab6710 -- 10.0.1.252:6812/22853 --> mds0 10.0.1.252:6802/22824 -- client_request(client4107:309 lookup #1/dir.0.run0) v1 -- ?+0 0x7f91d402e090
2010-10-26 19:33:20.912713 7f91dcab4710 -- 10.0.1.252:6812/22853 <== mds0 10.0.1.252:6802/22824 313 ==== client_reply(???:309 = 0 Success) v1 ==== 569+0+0 (3441130751 0 0) 0x123d050
2010-10-26 19:33:20.912805 7f91ddab6710 -- 10.0.1.252:6812/22853 --> mds0 10.0.1.252:6802/22824 -- client_request(client4107:310 mknod #10000000000/file.client4107.153) v1 -- ?+0 0x7f91d402e430
2010-10-26 19:33:20.915124 7f91dcab4710 -- 10.0.1.252:6812/22853 <== mds0 10.0.1.252:6802/22824 314 ==== client_reply(???:310 = 0 Success unsafe) v1 ==== 582+0+0 (41188764 0 0) 0x123d050
2010-10-26 19:33:20.915221 7f91ddab6710 -- 10.0.1.252:6812/22853 --> mds0 10.0.1.252:6802/22824 -- client_request(client4107:311 lookup #1/dir.0.run0) v1 -- ?+0 0x7f91d402e430
2010-10-26 19:33:20.916240 7f91dcab4710 -- 10.0.1.252:6812/22853 <== mds0 10.0.1.252:6802/22824 315 ==== client_reply(???:311 = 0 Success) v1 ==== 569+0+0 (174323478 0 0) 0x1230380
2010-10-26 19:33:20.916322 7f91ddab6710 -- 10.0.1.252:6812/22853 --> mds0 10.0.1.252:6802/22824 -- client_request(client4107:312 mknod #10000000000/file.client4107.154) v1 -- ?+0 0x7f91d402e940
2010-10-26 19:33:20.918674 7f91dcab4710 -- 10.0.1.252:6812/22853 <== mds0 10.0.1.252:6802/22824 316 ==== client_reply(???:312 = 0 Success unsafe) v1 ==== 582+0+0 (1725618510 0 0) 0x123d050
2010-10-26 19:33:20.918765 7f91ddab6710 -- 10.0.1.252:6812/22853 --> mds0 10.0.1.252:6802/22824 -- client_request(client4107:313 lookup #1/dir.0.run0) v1 -- ?+0 0x7f91d402e940
2010-10-26 19:33:20.919767 7f91dcab4710 -- 10.0.1.252:6812/22853 <== mds0 10.0.1.252:6802/22824 317 ==== client_reply(???:313 = 0 Success) v1 ==== 569+0+0 (3068357382 0 0) 0x1230380

Notably, a repeated lookup on the parent dir. That should get cached, either via a dentry lease or directory cap.

Actions
Copy link
 #1

Updated by Sage Weil over 13 years ago

  • Subject changed from uclient dentry leasing/caps not working to mds: change ifile state mix->sync on (many) lookups?
  • Category changed from 11 to 1

Nothing wrong on the client.. it's just that the mds has / (a subtree root) in the MIX state, and file_eval doesn't do mix->sync on subtree roots. The idea is that we'll switch states if we are asked to for some reason, by someone rdlocking or wrlocking, and hopefully be in the state the workload most frequently wants. The problem is just that lookup doesn't toggle it. We need some heuristic there, probably.

Actions
Copy link
 #2

Updated by Sage Weil over 13 years ago

  • Target version changed from v0.23 to 12
Actions
Copy link
 #3

Updated by Sage Weil over 13 years ago

  • Translation missing: en.field_position deleted (319)
  • Translation missing: en.field_position set to 316
Actions
Copy link
 #4

Updated by Sage Weil almost 13 years ago

  • Target version changed from 12 to 19
  • Translation missing: en.field_position deleted (372)
  • Translation missing: en.field_position set to 442
Actions
Copy link
 #5

Updated by Sage Weil over 12 years ago

  • Priority changed from Normal to Low
Actions
Copy link
 #6

Updated by Sage Weil over 12 years ago

  • Target version deleted (19)
Actions
Copy link
 #7

Updated by Sage Weil over 11 years ago

  • Project changed from Ceph to CephFS
  • Category deleted (1)
Actions
Copy link
 #8

Updated by Sage Weil over 11 years ago

  • Assignee set to Anonymous

csyn is now called ceph-syn

and --debug-ms 1 to see those messages go by!

Actions
Copy link
 #9

Updated by Anonymous over 11 years ago

  • Status changed from New to Closed
3 Node Cluster:
ceph version 0.56.1 (e4a541624df62ef353e754391cbbb707f54b16f7)
  1. cat /etc/ceph/ceph.conf
    [global]osd_journal_size = 1024
    filestore_xattr_use_omap = true
    auth cluster required = cephx
    auth service required = cephx
    auth client required = cephx
    [osd] debug ms = 1
    osd journal size = 1000
    filestore xattr use omap = true
    osd heartbeat interval = 12
    [mon.a] host = centos1
    mon addr = 10.1.10.123:6789
    [mon.b] host = centos2
    mon addr = 10.1.10.124:6789
    [mon.c] host = centos3
    mon addr = 10.1.10.125:6789
    [mds.a] debug mds = 5
    host = centos1
    [osd.0] host = centos1
    [osd.1] host = centos1
    [osd.2] host = centos1
    [osd.3] host = centos2
    [osd.4] host = centos2
    [osd.5] host = centos2
    [osd.6] host = centos3
    [osd.7] host = centos3
    [osd.8] host = centos3

Ran:
ceph-syn --syn makefiles 1000 1 0 -m 10.1.10.125

Multiple times.
no errors.
appears the "Success unsafe" issue has been resolved.

Actions
Copy link

Also available in: Atom PDF