mirror of
https://github.com/trapexit/mergerfs.git
synced 2026-10-26 19:01:56 -04:00
26c10d8a2e
After a successful _remove_thread_scaling_locked, the monitor set expected_count via thread_count(), which returns the pre-shrink count because the removal is deferred (only _remove_count is incremented; the actual _threads erase happens asynchronously when a worker claims the removal). This caused two problems: 1. On the next cycle, the deferred removal makes thread_count() return count-1, which differs from expected_count (count), triggering the external-scaling-interference detector and wasting the cycle. 2. If the worker hasn't exited yet, thread_count() still equals expected_count, so the monitor evaluates throughput with the pre-shrink thread count still in effect, potentially reversing direction before the shrink's effect is measurable. Fix: compute expected_count arithmetically (count-1 for shrink, count+1 for grow) using the authoritative pre-operation count read under _scaling_mutex, reflecting the intended outcome rather than the racy current state. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| acutest | ||
| boost | ||
| CLI11 | ||
| fmt | ||
| khash | ||
| libfuse | ||
| nonstd | ||
| rapidhash | ||
| scope_guard | ||
| subprocess | ||