diff options
author | Sage Weil <sage@inktank.com> | 2013-06-08 17:38:07 -0700 |
---|---|---|
committer | Sage Weil <sage@inktank.com> | 2013-06-08 22:25:47 -0700 |
commit | 860d42a37ef902272f0eff13e764e67563c22229 (patch) | |
tree | d3b115286dd35d691e80b15c63c1e1028bce0330 | |
parent | 48f8d6e3ffe9fc5bb71b362e3059ffb2da69926b (diff) | |
download | ceph-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.cc | 2 |
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); |