From 93f8b14de45042c310481c663bf8bf1e95f11a64 Mon Sep 17 00:00:00 2001 From: Xiubo Li Date: Thu, 31 Aug 2023 17:30:44 +0800 Subject: [PATCH] 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 (cherry picked from commit 68179ae21384b70c284026ac2b3dbf9f318e9af7) --- src/mds/Locker.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/mds/Locker.cc b/src/mds/Locker.cc index 4f362c8b109d9..427518524e65a 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; } } -- 2.39.5