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

src/mds/Locker.cc

@@ -1109,7 +1109,8 @@ void Locker::eval_gather(SimpleLock *lock, bool first, bool *pneed_issue, MDSCon
 		 (~lock->gcaps_allowed(CAP_LONER, next) & loner_issued) == 0 &&
 		 (~lock->gcaps_allowed(CAP_XLOCKER, next) & xlocker_issued) == 0)) &&
       lock->get_state() != LOCK_SYNC_MIX2 &&  // these states need an explicit trigger from the auth mds
-      lock->get_state() != LOCK_MIX_SYNC2
+      lock->get_state() != LOCK_MIX_SYNC2 &&
+      !(lock->get_sm() == &sm_filelock && !in->client_need_snapflush.empty()) // revoke Fb caps
       ) {
     dout(7) << "eval_gather finished gather on " << *lock
 	    << " on " << *lock->get_parent() << dendl;