Revival of #31703 with all outstanding review feedback addressed.
EmplaceCoinInternalDANGER
is unit and fuzz tested now, and memory accounting is fixed- Warning and logging moved from
FlushStateToDisk
toCCoinsViewDB::BatchWrite
, ensuring AssumeUTXO snapshot writes also display progress warnings - Removed the redundant changed counter in
BatchWrite
since we now trackdirty_count
directly - All instances use
dirty_count
(not num_dirty) and parameter alignment is corrected - The first commit of https://github.com/bitcoin/bitcoin/pull/33512/commits was also cherry-picked since there was a silent merge conflict after the addition of https://github.com/bitcoin/bitcoin/pull/32602/files#diff-1ef3b6a1936b50f3d5ec4a1786d9e2d63d1a3e1815b103e67f20601995f355b4R312-R321
It’s also related to #32313 which fixes a few more accounting inconsistencies in this area
Since #28280 and #28233, the percentage of dirty entries in the cache when a flush happens may in practice be far from 100%. The log output, the decision to warn about a large flush (#31534), and the disk-full detection, however always use the entire size of the cache.
Fix this by keeping track of the number of dirty entries in
CCoinsViewCache
, and using that number. We’ve dropped the usage ofDynamicMemoryUsage
as it’s the wrong metric, even before the non-wiping flushes were introduced (if everything is dirty, memory usage is correlated with, but not the same as, the amount of disk space written or used). They could be improved by keeping track of proper write size estimates in a follow-up, but here we’re just using a fixed 48 bytes per entry estimate.