Project

General

Profile

Actions

Bug #63133

closed

The dirty caps of the fuse client are not flushed in a timely manner, may cause MDS_CLIENT_RECALL

Added by lei liu 7 months ago. Updated 7 months ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

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

Description

I have noticed that some inodes in the client have long-lasting dirty caps, and they are not reclaimed even during MDS recall caps, resulting in the occurrence of MDS_CLIENT_RECALL messages in the system. It was found that when an inode holds Fx caps and setattr is performed on that inode to modify mtime, it acquires dirty caps. However, these dirty caps may remain unflushed for an extended period. Should the FUSE client flush the dirty caps after setattr? I have observed that NFS-Ganesha, after calling setattr, actively invokes the ll_sync_inode function to flush the dirty caps.

client cache dump info:

{
"path": "#0x1000023d4dd",
"disconnected": 1,
"ino": "0x1000023d4dd",
"snapid": "head",
"ctime": "2023-10-08T14:40:53.467607+0800",
"btime": "2023-10-08T14:40:07.724250+0800",
"mode": "040755",
"uid": 0,
"gid": 0,
"nlink": 1,
"size": 0,
"max_size": 0,
"truncate_seq": 1,
"truncate_size": 18446744073709551615,
"mtime": "212121.000000",
"atime": "212121.000000",
"time_warp_seq": 1,
"change_attr": 2,
"layout": {
"stripe_unit": 0,
"stripe_count": 0,
"object_size": 0,
"pool_id": -1,
"pool_ns": ""
},
"dir_layout": {
"dir_hash": 2,
"unused1": 0,
"unused2": 0,
"unused3": 0
},
"complete": false,
"ordered": false,
"version": 12,
"xattr_version": 1,
"flags": 0,
"dir_hashed": 0,
"dir_replicated": 0,
"caps": [ {
"auth": 1,
"mds": 0,
"ino": "0x1000023d4dd",
"cap_id": 1,
"issued": "pAsLsXsFsx",
"wanted": "AsLsXsFsx",
"seq": 11,
"issue_seq": 11,
"mseq": 0,
"gen": 0
}
],
"auth_cap": 0,
"dirty_caps": "Fx",
"shared_gen": 1,
"cache_gen": 0,
"hold_caps_until": "0.000000",
"snaprealm": {
"ino": "0x1",
"nref": 12,
"created": "0",
"seq": "1",
"parent_ino": "0x0",
"parent_since": "1",
"prior_parent_snaps": [],
"my_snaps": [],
"children": []
},
"reported_size": 0,
"ref": 1,
"ll_ref": 0
}

ENV:
FUSE client: "ceph_version": "ceph version 15.2.17 (8a82819d84cf884bd39c17e3236e0632ac146dc4) octopus (stable)"


Related issues 1 (1 open0 closed)

Related to CephFS - Bug #62979: client: queue a delay cap flushing if there are ditry caps/snapcapsPending BackportXiubo Li

Actions
Actions #1

Updated by lei liu 7 months ago

sorry,This is the same bug as https://tracker.ceph.com/issues/62979

Actions #2

Updated by Venky Shankar 7 months ago

  • Related to Bug #62979: client: queue a delay cap flushing if there are ditry caps/snapcaps added
Actions #3

Updated by Venky Shankar 7 months ago

  • Status changed from New to Duplicate
Actions

Also available in: Atom PDF