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>
(cherry picked from commit 37370ed8980841404b17b28a0191b8ba16172566)

diff --git a/src/mds/PurgeQueue.cc b/src/mds/PurgeQueue.cc
index 56c962d19ba83bc1032b144d0dfc9a99428262c2..dfa5764c01d036b7d977ae9dbd55df8d85299090 100644 (file)
--- a/src/mds/PurgeQueue.cc
+++ b/src/mds/PurgeQueue.cc
@@ -373,7 +373,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) {
@@ -847,4 +847,3 @@ std::string_view PurgeItem::get_type_str() const
     return "UNKNOWN";
   }
 }
-