deardeng commented on code in PR #67313:
URL: https://github.com/apache/doris/pull/67313#discussion_r3888493523
##########
be/src/io/cache/block_file_cache.cpp:
##########
@@ -2194,8 +2194,6 @@ std::string BlockFileCache::reset_capacity(size_t
new_capacity) {
queue_released = remove_blocks(_ttl_queue);
ss << " ttl_queue released " << queue_released;
- _disk_resource_limit_mode = true;
- _disk_limit_mode_metrics->set_value(1);
ss << " total_space_released=" << space_released;
Review Comment:
You're right that try_reserve_during_async_load() had no capacity
enforcement of its own: it returned !_disk_resource_limit_mode || removed_size
>= size, so with the mode off it admitted unconditionally without ever looking
at _capacity. Rather than keep leaning on a disk-pressure flag for this, the
function now computes an eviction target from the capacity gap (_cur_cache_size
+ size - _capacity), raised to size while under disk pressure, and evicts
against that target. A zero target returns before touching any LRU queue, so
the common admission path is unchanged. Two tests added: one holds
_async_open_done false across a 100→30 shrink and asserts the cache stays
within the new capacity (fails without the change), one asserts a
sufficient-capacity reserve still admits without evicting anything.
One correction though: the old assignment was not "the only guard on this
path" in any lasting sense. On master the next monitor tick clears it within
one file_cache_background_monitor_interval_ms — either through the pre-clear
when _capacity > _cur_cache_size, or through the exit branch when the disk sits
below the exit threshold. The window was ~5s wide, not closed. The new code
actually closes it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
