Bug #11522: FLUSHSNAP_ACKs are not always sent back on unexpected FLUSHSNAP - CephFS - Ceph

Actions

Copy link

Bug #11522

closed

FLUSHSNAP_ACKs are not always sent back on unexpected FLUSHSNAP

Added by Greg Farnum almost 9 years ago. Updated almost 9 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Zheng Yan

Category:

Target version:

% Done:

Source:

Development

Tags:

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(FS):

Labels (FS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

There is a PR to make the MDS always send back a FLUSHSNAP_ACK: https://github.com/ceph/ceph/pull/4523

But I guess the clients are issuing these at times when the MDS doesn't expect them, and then the clients hang up. We should fix this on both sides if possible so it works if either end is upgraded.

Actions

Copy link

Updated by Zheng Yan almost 9 years ago

client creates cap_snap and sends FLUSHSNAP message to MDS even when snap notification contains no new snap (snap removal). that's why MDS mau receive unexpected FLUSHSNAP message. client releases cap_snap and related resource only after it receives FLUSHSNAP_ACK, For kclient, it does not hang, the symptom of this bug is that kernel warns busy inodes after umount.

The kclient does not make sure cap snap get flushed properly on umount. I'm working on fixing it.

Actions

Copy link