之前的文章中提到，hived v1.26.0rc5 可以有两种执行状态，压缩block_log以及非压缩block_log，据说压缩后的block_log只占非压缩方式一半的空间，大大地节省了空间开支。
(图源 ：pixabay)
虽然我已经在本地机器(Ubuntu 22.04 LTS)上，成功地以非压缩block_log方式执行，并且成功地在V1.26.0上出块，但是节省空间还是颇有吸引力的，于是决定尝试一下。
帮助信息
首先看看compress_block_log的帮助信息：
compress_block_log_v1.26.0rc5 --help
帮助信息一目了然，还不错：
其中-i指定输入目录（包含block_log文件），-o指定输出目录，-j执行用的线程数。
VPS上尝试
于是我在VPS上，执行如下操作
compress_block_log_v1.26.0rc5 -i .hived/blockchain/ -j 10 -o .hived/blockchain_compressed
注意，执行上述命令之前，需要先创建对应的输出目录（本例中为 .hived/blockchain_compressed），否则会报错退出。
但是我的VPS给了我一个大大的惊喜惊吓😨：
提示信息最关键的是：预估剩余时间为54155秒，也就是说还需要15小时（咦，我的数学不错嘛）。
我查看了输出目录，发现没啥输出内容，所以我断定，这个时间只是重建artifact文件的时间。然后还有实际压缩，还有replay的时间，想想就头大，于是果断放弃使用VPS尝试。
本地机上尝试
虽然放弃在VPS上尝试，但是又不甘心，于是在测试机上进行尝试，发现进度还不错：
这个估算大致完成时间8400秒左右，折合2.33小时左右。
查看了一下输出目录，这个过程中，基本上没有输出，所以断定是先生成artifact文件：
生成artifact文件实际耗时3666秒，也就是说几乎正好一个小时：
接下来是压缩并写入压缩block_log的过程了，看起来还很快：
原以为后边显示的百分比是进度，后来才看明白，后边百分比显示的是压缩后节省的空间所占比例。😳
大概运行了两个小时以后，还差大概200W个块，就完成啦，曙光就在眼前：
终于全部完成啦：
压缩并写入文件耗时8045秒，大概是2小时15分钟的样子。
也就是说，在我本地测试机上执行compress_block_log，一共耗时3小时15分钟：其中生成artifact文件耗时一个小时；压缩并写入文件，耗时2小时15分钟。
压缩后的文件信息：
其中block_log文件占用空间省了一半，还是非常可观的。另外需要说明的是，我们选择的是默认的压缩比率，如果选择更大的压缩比，空间占用会更低。
Replay & 执行
剩下的应该和使用非压缩方式运行hived没啥区别了，因为这份本地用例我是从hived v1.25.0版本copy过来的，所以要先replay一下，然后就可以正常运行了。
不replay，直接执行的话，会提示如下信息：
3289938ms chain_plugin.cpp:641 check_data_consisten ] Replaying is not finished. Synchronization is not allowed. { "block_log-head": 68535116, "state-head": 0 }
执行replay指令：
hived_v1.26.0rc5 --replay-blockchain
又开始Replay了：
剩下的就是等待了，按以往经验，测试机上replay大概要6-8小时。
其它
通过对比VPS上以及本地机器上的压缩block_log所耗费的时间（VPS上第一步我就放弃了），可见CPU主频以及磁盘IO性能对这个操作影响还是极大的（尤其是磁盘IO)。
测试机上我用的是SATA SSD，因为我的NVME空间几乎被占满啦，否则在NVME上进行这个操作应该更快。
我找了一下 @blocktrades 前段时间的文章，里边有关于block_log.artifacts以及compress_block_log工具的说明：
其中这句话(关于block_log.artifacts生成时间），直接让我破防啦：
Note that this task is now only IO bottlenecked by the time to read the block_log file backwards, so on a set of 4xraided NVME drives it takes as little as 7.5 minutes.
我想把我的VPS以及我的大电脑都砸了。后来仔细想想，还是舍不得，没钱认命吧。