On 4/29/22 10:46 AM, Yan, Zheng wrote:
On Thu, Apr 28, 2022 at 11:42 PM Xiubo Li <xiubli@xxxxxxxxxx> wrote:
For example if the Frwcb caps are being revoked, but only the Fr
caps is still being used then the kclient will skip releasing them
all. But in next turn if the Fr caps is ready to be released the
Fw caps maybe just being used again. So in corner case, such as
heavy load IOs, the revocation maybe stuck for a long time.
This does not make sense. If Frwcb are being revoked, writer can't get
Fw again. Second, Frwcb are managed by single lock at mds side.
Partial releasing caps does make lock state transition possible.
Yeah, you are right. Checked the __ceph_caps_issued() it really has
removed the caps being revoked already.
Thanks Zheng.
Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
---
fs/ceph/caps.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 0c0c8f5ae3b3..7eb5238941fc 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -1947,6 +1947,13 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
/* The ones we currently want to retain (may be adjusted below) */
retain = file_wanted | used | CEPH_CAP_PIN;
+
+ /*
+ * Do not retain the capabilities if they are under revoking
+ * but not used, this could help speed up the revoking.
+ */
+ retain &= ~((revoking & retain) & ~used);
+
if (!mdsc->stopping && inode->i_nlink > 0) {
if (file_wanted) {
retain |= CEPH_CAP_ANY; /* be greedy */
--
2.36.0.rc1
