mds: just wait the client flushes the snap and dirty buffer

When truncating the inode we will just set the ifile lock state to
LOCK_XLOCKSNAP and then try to revoke the 'Fb' caps, but if the
client couldn't release the 'Fb' cap in time just replies with a
normal cap updating request, the MDS will successfully transfer
the ifile's lock state to LOCK_EXCL, which is stable.

That means the MDS will wake up the truncating request and continue
truncating the objects from Rados without waiting the clients to
flush the diry buffer.

Fixes: commit 9c65920e7f6 ("mds: force client flush snap data before
		truncating objects")
Fixes: https://tracker.ceph.com/issues/62580
Signed-off-by: Xiubo Li <xiubli@redhat.com>

diff --git a/src/mds/Locker.cc b/src/mds/Locker.cc
index b4a28fb8379fbdd1c40592bc6d19520ae0d26587..4d1a2f498b10a1cfd76e62864573d5d32b6e2487 100644 (file)
--- a/src/mds/Locker.cc
+++ b/src/mds/Locker.cc
@@ -1237,6 +1237,19 @@ void Locker::eval_gather(SimpleLock *lock, bool first, bool *pneed_issue, MDSCon
          send_lock_message(lock, LOCK_AC_SYNC, softdata);
        }
        break;
+      case LOCK_XLOCKSNAP:
+       if (lock->get_sm() == &sm_filelock) {
+         int pending = lock->gcaps_allowed(CAP_ANY) ||
+                       lock->gcaps_allowed(CAP_LONER) ||
+                       lock->gcaps_allowed(CAP_XLOCKER);
+         int revoke = ~pending & (loner_issued | other_issued | xlocker_issued);
+
+         // wait for 'Fb' to be revoked
+         if (revoke & CEPH_CAP_GBUFFER) {
+           return;
+         }
+       }
+       break;
       }
 
     }