From fe86a7cd480b32463da900db764d2d11a2bea095 Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Fri, 28 Apr 2023 18:50:33 -0400 Subject: [PATCH] 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. --- src/node/blockstorage.cpp | 6 ++++-- src/node/blockstorage.h | 13 +++++++++++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/src/node/blockstorage.cpp b/src/node/blockstorage.cpp index 78416ec576..157acf1097 100644 --- a/src/node/blockstorage.cpp +++ b/src/node/blockstorage.cpp @@ -644,7 +644,7 @@ bool BlockManager::FindBlockPos(FlatFilePos& pos, unsigned int nAddSize, unsigne // when the undo file is keeping up with the block file, we want to flush it explicitly // when it is lagging behind (more blocks arrive than are being connected), we let the // undo block write case handle it - finalize_undo = (m_blockfile_info[nFile].nHeightLast == (unsigned int)active_chain.Tip()->nHeight); + finalize_undo = (m_blockfile_info[nFile].nHeightLast == m_undo_height_in_last_blockfile); nFile++; if (m_blockfile_info.size() <= nFile) { m_blockfile_info.resize(nFile + 1); @@ -660,6 +660,7 @@ bool BlockManager::FindBlockPos(FlatFilePos& pos, unsigned int nAddSize, unsigne } FlushBlockFile(!fKnown, finalize_undo); m_last_blockfile = nFile; + m_undo_height_in_last_blockfile = 0; // No undo data yet in the new file, so reset our undo-height tracking. } m_blockfile_info[nFile].AddBlock(nHeight, nTime); @@ -749,8 +750,9 @@ bool BlockManager::WriteUndoDataForBlock(const CBlockUndo& blockundo, BlockValid // the FindBlockPos function if (_pos.nFile < m_last_blockfile && static_cast(block.nHeight) == m_blockfile_info[_pos.nFile].nHeightLast) { FlushUndoFile(_pos.nFile, true); + } else if (_pos.nFile == m_last_blockfile && static_cast(block.nHeight) > m_undo_height_in_last_blockfile) { + m_undo_height_in_last_blockfile = block.nHeight; } - // update nUndoPos in block index block.nUndoPos = _pos.nPos; block.nStatus |= BLOCK_HAVE_UNDO; 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 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