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>
Reviewed-by: Greg Farnum <greg@inktank.com>
This commit is contained in:
Sage Weil 2013-06-08 17:38:07 -07:00
parent 3f2017fb17
commit 9b012e234a

View File

@ -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);