summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSage Weil <sage@newdream.net>2010-08-05 13:53:18 -0700
committerSage Weil <sage@newdream.net>2010-08-05 13:53:40 -0700
commit0eb6cd49f6e3ec523787d09cf08d3179be270db4 (patch)
tree7974963003e0b8ef26fdfb3a8120c6b4b588a01b
parente9d177443134bc4ac1c1393af69e2a8704bcac09 (diff)
downloadop-kernel-dev-0eb6cd49f6e3ec523787d09cf08d3179be270db4.zip
op-kernel-dev-0eb6cd49f6e3ec523787d09cf08d3179be270db4.tar.gz
ceph: only queue async writeback on cap revocation if there is dirty data
Normally, if the Fb cap bit is being revoked, we queue an async writeback. If there is no dirty data but we still hold the cap, this leaves the client sitting around doing nothing until the cap timeouts expire and the cap is released on its own (as it would have been without the revocation). Instead, only queue writeback if the bit is actually used (i.e., we have dirty data). If not, we can reply to the revocation immediately. Signed-off-by: Sage Weil <sage@newdream.net>
-rw-r--r--fs/ceph/caps.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 51546d5..7bf182b 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -2384,7 +2384,7 @@ static void handle_cap_grant(struct inode *inode, struct ceph_mds_caps *grant,
ceph_cap_string(cap->issued),
ceph_cap_string(newcaps),
ceph_cap_string(revoking));
- if (revoking & CEPH_CAP_FILE_BUFFER)
+ if (revoking & used & CEPH_CAP_FILE_BUFFER)
writeback = 1; /* initiate writeback; will delay ack */
else if (revoking == CEPH_CAP_FILE_CACHE &&
(newcaps & CEPH_CAP_FILE_LAZYIO) == 0 &&
OpenPOWER on IntegriCloud