mds/PurgeQueue: don't consider filer_max_purge_ops when _calculate_ops

_calculate_ops relying on a config which can be modified on the fly will cause a bug. e.g.
1. A file has 20 objects and filer_max_purge_ops config was 10.
2. calling PurgeQueue::_execute_item and _calculate_ops returns 10, so ops_in_flight add 10.
3. adjust filer_max_purge_ops to 20 on the fly
4. calling PurgeQueue::_execute_item_complete and _calculate_ops returns 20, so ops_in_flight dec 20.
5. since ops_in_flight is uint64, this cause an overflow which makes ops_in_flight far more
greater than max_purge_ops and can't go back to a reasonable value.

filer_max_purge_ops will still work when _do_purge_range, so it's ok to ignore it here.

Fixes: https://tracker.ceph.com/issues/58008
Signed-off-by: haoyixing <haoyixing@kuaishou.com>

diff --git a/src/mds/PurgeQueue.cc b/src/mds/PurgeQueue.cc
index cb6c389dd431a7e69dc002f3ea475bcc14ec801e..e8f416bd97ac7112e60943cd2c2d263ec70c797b 100644 (file)
--- a/src/mds/PurgeQueue.cc
+++ b/src/mds/PurgeQueue.cc
@@ -376,7 +376,7 @@ uint32_t PurgeQueue::_calculate_ops(const PurgeItem &item) const
     const uint64_t num = (item.size > 0) ?
       Striper::get_num_objects(item.layout, item.size) : 1;
 
-    ops_required = std::min(num, g_conf()->filer_max_purge_ops);
+    ops_required = num;
 
     // Account for deletions for old pools
     if (item.action != PurgeItem::TRUNCATE_FILE) {
@@ -850,4 +850,3 @@ std::string_view PurgeItem::get_type_str() const
     return "UNKNOWN";
   }
 }
-