昨晚在尝试在备机上replay STEEM，等了好久也不见响应，想想可能是反应迟钝，按着以往的经验，4-6个小时肯定会replay完成，于是就放到一旁忙其它事情去了。

(图源 ：pixabay)

结果消停了三两个小时，还没等我去看replay是否完成呢，我用于监控另外一个程序的报警器就开始嗷嗷报警了。

登录主机，看了一眼，并没有搞明白发生了什么事情，然后打算看一样另外那个程序的配置文件，发现打开文件时出现如下提示：

"E297: Write error in swap file"

啥？明明就是打开个小文件，咋还用到swap file了，百度一下，说这种出现这类错误有可能是硬盘满了，然后看了一下，果然硬盘占用已经达到100%。

想想我就操作STEEM了，过去一看，果然罪魁祸首在这呢：

可是这个问题咋引起的呢？难道是因为Soft fork 0.22.2？我换用0.22.1 replay 问题依旧，block_log.index，不讲道理地迅速增长。

为此我又尝试了清除block_log.index & shared_memory.bin， 也尝试重启VPS，问题依旧，这就让我有些抓狂了。

于是在群里向@ety001 以及 @abit请教，均判断可能是block_log 文件损坏，@ety001 还提供了 @someguy123 提供的一个block_log下载链接。

: ${BC_RSYNC="rsync://files.privex.io/steem/block_log"}

确定了问题所在，剩余的事情就简单了，我用truncate把文件尾剪裁掉一部分

truncate -s 245G block_log

(咳咳，手抖，裁多了，裁了约10G，其实裁掉1-2G就够用了。（让文件比rsync://files.privex.io/steem/block_log block_log这个小即可）

用rsync同步一下文件：

rsync -av --progress --append rsync://files.privex.io/steem/block_log block_log

之所以没用--append-verify而使用--append，因为我觉得我网络挺好的，不用校验。

弄完之后，再replay，终于出现熟悉的画面：

早晨起床看，已经恢复了正常：

这个折腾劲啊，不过总算折腾好了，让我热泪满眶，下次再也不敢瞎折腾了。

相关链接

• https://github.com/Someguy123/steem-docker/blob/master/run.sh#L40

---

Vote For Me As Witness
https://steemit.com/~witnesses type in oflyhigh and click VOTE

Vote @oflyhigh via Steemconnect
Thank you!