From: haoyixing Date: Tue, 8 Nov 2022 08:13:38 +0000 (+0800) Subject: mds/PurgeQueue: don't consider filer_max_purge_ops when _calculate_ops X-Git-Tag: v18.1.0~678^2 X-Git-Url: http://git.apps.os.sepia.ceph.com/?a=commitdiff_plain;h=37370ed8980841404b17b28a0191b8ba16172566;p=ceph.git 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 --- diff --git a/src/mds/PurgeQueue.cc b/src/mds/PurgeQueue.cc index cb6c389dd431a..e8f416bd97ac7 100644 --- 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"; } } -