github-actions[bot] commented on code in PR #67313:
URL: https://github.com/apache/doris/pull/67313#discussion_r3888602949
##########
be/src/io/cache/block_file_cache.cpp:
##########
@@ -2577,6 +2569,15 @@ BlockFileCache::get_hot_blocks_meta(const
UInt128Wrapper& hash) const {
bool BlockFileCache::try_reserve_during_async_load(size_t size,
std::lock_guard<std::mutex>& cache_lock) {
+ size_t evict_target =
Review Comment:
[P1] Do not evict loader-visible blocks before readiness
The DB loader buffers up to 10k `BatchLoadArgs` outside `_mutex`. With a
restored capacity overage, a request can lazy-load buffered K, release it, and
this new full-gap path can synchronously delete K's file; the pending batch
then sees no cell and re-adds K as `DOWNLOADED` without checking storage.
Because metadata deletion is queued, an immediate direct lookup can recreate
the same stale cell too. Normal readers fall back and self-heal, but only after
a false cache hit, failed local/peer work, and lost cache warmth.
The full-gap target also makes a foreground miss delete the entire restored
overage under the global cache mutex, doing per-cell file deletes/listings and
blocking every cache access. This is distinct from the existing over-capacity
publication thread: it is delete-then-stale-republication plus unbounded
foreground cleanup introduced before `_async_open_done`. Please avoid or
generation-fence eviction of loader-visible cells until loading finishes,
bound/defer the cleanup, and add held-loader and large-overage regressions.
--
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]
