From: Xiubo Li <xiubli@redhat.com>
Date: Thu, 31 Aug 2023 09:30:44 +0000 (+0800)
Subject: mds: just wait the client flushes the snap and dirty buffer
X-Git-Tag: v19.3.0~211^2
X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=68179ae21384b70c284026ac2b3dbf9f318e9af7;p=ceph.git

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 b4a28fb8379f..4d1a2f498b10 100644
--- 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;
       }
 
     }