Require nLastBlockFile to be the highest numbered file. #6857

pull morcos wants to merge 1 commits into bitcoin:master from morcos:nLastBlockFile changing 1 files +1 −1

morcos commented at 7:44 PM on October 19, 2015: member
nLastBlockFile is used to determine which block file new blocks are written to. During a reindex, it could previously hop around if the tip of the active chain was not always in the highest numbered block file encountered so far.

There is not a known problem with the existing behavior, but I think the semantics of having nLastBlockFile actually refer to the highest number file and not just the one in which the latest tip was found during a reindex makes sense. The difference in behavior is that during a reindex with corrupted or out of order data:
- in the old code, nLastBlockFile will point to the block file with the last valid block (chainActive.Tip())
- after this pull, nLastBlockFile will point to the highest numbered block file which contains a valid block (on chainActive). Future block writes will start looking at nLastBlockFile and increment it until they find a block file with unused space enough for the write. @sipa, I don't know if you think its worth the review time to verify this doesn't mess anything up. But I find the logic confusing as is.

Require nLastBlockFile to be the highest numbered file.

nLastBlockFile is used to determine which block file new blocks are written to.  During a reindex, it could previously hop around if the tip of the active chain was not always in the highest numbered block file encountered so far.

c2bb5e7fe1

laanwj added the label UTXO Db and Indexes on Oct 20, 2015
laanwj commented at 12:36 PM on October 20, 2015: member

Concept ACK

in src/main.cpp:None in c2bb5e7fe1

2502 | @@ -2503,7 +2503,7 @@ bool FindBlockPos(CValidationState &state, CDiskBlockPos &pos, unsigned int nAdd
2503 |          pos.nPos = vinfoBlockFile[nFile].nSize;
2504 |      }
2505 |  
2506 | -    nLastBlockFile = nFile;
2507 | +    nLastBlockFile = std::max(nLastBlockFile, (int)nFile);

Diapolo commented at 8:05 PM on October 21, 2015:

Why is nFile unsigned btw?

morcos commented at 3:04 PM on November 5, 2015: member

Oops. In light of #6948 I think this might be broken in determining where undoFiles are written. Since there wasn't a known problem, I'm abandoning this and putting off worrying about clearing up the logic.
morcos closed this on Nov 5, 2015
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels