summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSage Weil <sage@inktank.com>2013-06-08 17:38:07 -0700
committerSage Weil <sage@inktank.com>2013-06-08 22:25:47 -0700
commit860d42a37ef902272f0eff13e764e67563c22229 (patch)
treed3b115286dd35d691e80b15c63c1e1028bce0330
parent48f8d6e3ffe9fc5bb71b362e3059ffb2da69926b (diff)
downloadceph-860d42a37ef902272f0eff13e764e67563c22229.tar.gz
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 <sage@inktank.com>
-rw-r--r--src/client/Client.cc2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/client/Client.cc b/src/client/Client.cc
index bddfa0a1996..0f064636bdb 100644
--- a/src/client/Client.cc
+++ b/src/client/Client.cc
@@ -2849,7 +2849,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);