It's official now, you can configure your hived node to get rid of some of the 490+ gigabytes of compressed block log burden. You can even shed all of it, but do you really want to and what if you change your mind?
Since the beginning of Hive blockchain (and its predecessor) there was that huge single file named block_log, mandatory for all nodes. A single file with a size of over 490 gigabytes now, requiring continuous disk space of its size. The block log revolution that comes into force with 1.27.7rc0 tag brings following improvements:
Let's examine the new modes in detail:
block_api. Good for transaction broadcaster.| mode name | blocks kept | replayable | the value of block-log-split option in config.ini |
|---|---|---|---|
| legacy | all | yes | -1 |
| split | all | yes | 9999 (default value now) |
| pruned | last n millions | sometimes | n > 0 |
| no-file | last 1 | no | 0 |
Wait a minute, you may say, the split mode number (9999) meets the condition of pruned one (> 0), there must be a mistake here. Let me explain in detail then - positive value of block-log-split option defines how many full millions of last irreversible blocks are to be kept in block log files. It means that when you set it to e.g. 90, all blocks will be kept for the time being, because Hive's got a little over 89 millions of blocks now. Thus for the time being the block log is not effectively pruned. After a while however, when the threshold of 90 millions is crossed, the file containing oldest (first) million of blocks will be pruned (deleted) and from that moment the block log will be effectively pruned. As you can see the boundary between split & pruned modes is blurred, but setting it to the biggest possible number (9999) means that your block log won't be pruned for the next 950+ years.
Now we're getting to the question why replay is available sometimes in pruned mode. Full replay (from block #1) requires all blocks to be present in block log, therefore it can be performed as long as block log is not effectively pruned due to combination of block-log-split value in configuration and current head block of the blockchain. After the oldest part file containing initial 1 million blocks is removed, the block log is effectively pruned and full replay is no longer possible.
Block log files of nodes configured with different values of block-log-split option. Note the file size differences.
block_log_util's new --split option or b) running hived configured to have split block log with legacy monolithic one provided in its blockchain directory, which triggers built-in auto-split mechanism. The former is recommended as it allows to generate the 490+ GB of split files into output directory other than the source one (possibly on different disk space).blockchain directory. Not only can smaller disk volumes be used, you can even consider placing older parts (i.e. the ones rarely used by hived) onto slower drives.block_log_part.???? where ???? stands for consecutive numbers beginning with 0001 followed by 0002, etc. Since each one contains up to a million of blocks, block_log_part.0001 contains blocks numbered 1 to 1 000 000, while block_log_part.0002 contains blocks numbered 1 000 001 to 2 000 000 and so on. Hived recognizes the block log files by their names, so don't change them or it becomes lost.