bug-fix: delayed flush of undo files

kallewoof · kallewoof · commit b49b34139ac3 · 2020-01-23T01:10:58.000+09:00
When creating blk and rev files, these are pre-allocated for performance reasons, and then truncated down to their final size after completion.
This works for blk files which are sequentially created, but since blocks are stored out of order, and since the undo data for blocks are stored sequentially (upon activation of the block), the rev file will be written to for awhile even after the blk file has been finalized. This change switches the flushing part to flush the *previous* undo file for the finalize (truncate) case, which addresses the problem, as we never write to the rev file 2 steps back.
diff --git a/src/validation.cpp b/src/validation.cpp
@@ -1735,8 +1735,14 @@ void static FlushBlockFile(bool fFinalize = false)
 {
     LOCK(cs_LastBlockFile);
 
+    // we want to finalize flush the previous undo file, as it will have been written to
+    // for awhile even after we've moved onto the next blk file; if we don't do this, we
+    // end up with a re-opened but unflushed rev file, resulting in pre-allocated but not
+    // returned disk space allocation
+    int previous_undo_file = fFinalize && nLastBlockFile > 0 ? nLastBlockFile - 1 : nLastBlockFile;
+
     FlatFilePos block_pos_old(nLastBlockFile, vinfoBlockFile[nLastBlockFile].nSize);
-    FlatFilePos undo_pos_old(nLastBlockFile, vinfoBlockFile[nLastBlockFile].nUndoSize);
+    FlatFilePos undo_pos_old(previous_undo_file, vinfoBlockFile[previous_undo_file].nUndoSize);
 
     bool status = true;
     status &= BlockFileSeq().Flush(block_pos_old, fFinalize);
