Prune: Support noncontiguous block files
In some corner cases, it may be possible for recent blocks to end up in the same block file as much older blocks. Previously, the pruning code would stop looking for files to remove upon first encountering a file containing a block that cannot be pruned, now it will keep looking for candidate files until the target is met and all other criteria are satisfied. This can result in a noncontiguous set of block files (by number) on disk, which is fine except for during some reindex corner cases, so make reindex preparation smarter such that we keep the data we can actually use and throw away the rest. This allows pruning to work correctly while downloading any blocks needed during the reindex. Rebased-From: c257a8c9a6397eee40734b235a4fdcb8045aec91 Github-Pull: #6221
This commit is contained in:
committed by
Wladimir J. van der Laan
parent
37b4e425af
commit
6cb70ca4ee
@@ -3040,9 +3040,9 @@ void FindFilesToPrune(std::set<int>& setFilesToPrune)
|
||||
if (nCurrentUsage + nBuffer < nPruneTarget) // are we below our target?
|
||||
break;
|
||||
|
||||
// don't prune files that could have a block within MIN_BLOCKS_TO_KEEP of the main chain's tip
|
||||
// don't prune files that could have a block within MIN_BLOCKS_TO_KEEP of the main chain's tip but keep scanning
|
||||
if (vinfoBlockFile[fileNumber].nHeightLast > nLastBlockWeCanPrune)
|
||||
break;
|
||||
continue;
|
||||
|
||||
PruneOneBlockFile(fileNumber);
|
||||
// Queue up the files for removal
|
||||
|
||||
Reference in New Issue
Block a user