diff options
author | Suhas Daftuar <sdaftuar@chaincode.com> | 2023-04-28 18:50:33 -0400 |
---|---|---|
committer | Suhas Daftuar <sdaftuar@chaincode.com> | 2023-07-14 14:47:00 -0400 |
commit | fe86a7cd480b32463da900db764d2d11a2bea095 (patch) | |
tree | 9f7db57e6636f0420fe1902daaefe0eb3b2a5b0a /src/node/blockstorage.h | |
parent | 01e5d6b105861ebf1216df6f1682004e44dd2544 (diff) | |
download | bitcoin-fe86a7cd480b32463da900db764d2d11a2bea095.tar.xz |
Explicitly track maximum block height stored in undo files
When writing a new block to disk, if we have filled up the current block file,
then we flush and truncate that block file (to free allocated but unused
space) before advancing to the next one. When this happens, we have to
determine whether to also flush and truncate the corresponding undo file.
Undo data is only written when blocks are connected, not when blocks are
received. Thus it's possible that the corresponding undo file already has all
the data it will ever have, and we should flush/truncate it as we advance
files; or it's possible that there is more data we expect to write, and should
therefore defer flush/truncation until undo data is later written.
Prior to this commit, we made the determination of whether the undo file was
full of all requisite data by comparing against the chain tip. This patch
replaces that dependence on validation data structures by instead just tracking
the highest height of any block written in the undo file as we go.
Diffstat (limited to 'src/node/blockstorage.h')
-rw-r--r-- | src/node/blockstorage.h | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/src/node/blockstorage.h b/src/node/blockstorage.h index c2e903e470..1344fa04de 100644 --- a/src/node/blockstorage.h +++ b/src/node/blockstorage.h @@ -128,6 +128,19 @@ private: RecursiveMutex cs_LastBlockFile; std::vector<CBlockFileInfo> m_blockfile_info; int m_last_blockfile = 0; + + // Track the height of the highest block in m_last_blockfile whose undo + // data has been written. Block data is written to block files in download + // order, but is written to undo files in validation order, which is + // usually in order by height. To avoid wasting disk space, undo files will + // be trimmed whenever the corresponding block file is finalized and + // the height of the highest block written to the block file equals the + // height of the highest block written to the undo file. This is a + // heuristic and can sometimes preemptively trim undo files that will write + // more data later, and sometimes fail to trim undo files that can't have + // more data written later. + unsigned int m_undo_height_in_last_blockfile = 0; + /** Global flag to indicate we should check to see if there are * block/undo files that should be deleted. Set on startup * or if we allocate more file space when we're in prune mode |