From: Sage Weil Date: Sun, 9 Jun 2013 00:38:07 +0000 (-0700) Subject: client: set issue_seq (not seq) in cap release X-Git-Tag: v0.64~3 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=9b012e234a924efd718826ab6a53b9aeb7cd6649;p=ceph.git client: set issue_seq (not seq) in cap release We regularly have been observing a stall where the MDS is blocked waiting for a cap revocation (Ls, in our case) and never gets a reply. We finally tracked down the sequence: - mds issues cap seq 1 to client - mds does revocation (seq 2) - client replies - much time goes by - client trims inode from cache, sends release with seq == 2 - mds ignores release because its issue_seq is 1 - mds later tries to revoke other caps - client discards message because it doesn't have the inode in cache The problem is simply that we are using seq instead of issue_seq in the cap release message. Note that the other release call site in encode_inode_release() is correct. That one is much more commonly triggered by short tests, as compared to this case where the inode needs to get pushed out of the client cache. Signed-off-by: Sage Weil Reviewed-by: Greg Farnum --- diff --git a/src/client/Client.cc b/src/client/Client.cc index 0b4d87b20669..155313e6446d 100644 --- a/src/client/Client.cc +++ b/src/client/Client.cc @@ -2848,7 +2848,7 @@ void Client::remove_cap(Cap *cap) ceph_mds_cap_item i; i.ino = in->ino; i.cap_id = cap->cap_id; - i.seq = cap->seq; + i.seq = cap->issue_seq; i.migrate_seq = cap->mseq; session->release->caps.push_back(i);