Project

General

Profile

Bug #11522

FLUSHSNAP_ACKs are not always sent back on unexpected FLUSHSNAP

Added by Greg Farnum over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/01/2015
Due date:
% Done:

0%

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

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.

History

#1 Updated by Zheng Yan over 4 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.

#2 Updated by Zheng Yan over 4 years ago

  • Status changed from New to Resolved
  • Regression set to No

by commit 585bc2bc6a7aeddf32e9c1d43d0aa01568e01d63

Also available in: Atom PDF