ToC
Syncthing 是一个开源去中心化分布式同步方案, 优点是免费, 数据自己掌控, 且没有任何容量或流量限制, 具体介绍和使用请访问其官网, 本文只是介绍使用过程中遇到的几个坑.
硬盘缓存解决方案导致 Syncthing 数据库错乱
在某台式上用 Windows Syncthing (SyncTrayzor) 后一段时间后出现类似 这里提到 的 log. 可以看出关键的一句是:
panic: leveldb/table: corruption on data-block (pos=0): checksum mismatch, want=0x222c5c3a got=0x6676beb6 [file=004278.ldb]
就是 Syncthing 用来存放同步内容哈希的数据库里某条记录跟实际文件的哈希对不上了. 以这条 log 前半段 “panic: leveldb/table: corruption on data-block” 搜索一下可以看到前人的一些讨论.
panic: leveldb/table: corruption on data-block · Issue #2734 · syncthing/syncthing
Panic: leveldb/table: corruption on data-block – Support – Syncthing Forum
Panic: leveldb/table possibly due to ssd caching? – Support – Syncthing Forum
首先看到有人建议先清掉 Syncthing 的数据库文件夹再重启一下让它自动重新建数据库. 于是 参考一下文档 找到 Windows 下的数据库文件夹位置. 看到唯一那个 index 开头的文件夹, 删掉. 删掉这个不会丢失用户自定义的设置和同步文件夹设置.
重建 index 根据同步文件夹大小和电脑 CPU 耗时不定, 200G & R5 2600 好像用了一个多小时.
重建之后随便加了一些文件测试同步, 似乎没有问题.
两三天之后, 问题重现. 根据上面查到的讨论开始怀疑是 AMD CPU 带的 StoreMI (用 SSD 给 HDD 加速的软硬件解决方案) 引起问题.
跟着 StoreMI 官方文档 开始把原本融合的两个盘拆开. 此处省略具体操作和电脑迁移数据时间 3 小时. 官方文档已经说得很详细了, 有不明白的, 请看多几遍文档.
之后再没发生类似问题.
由于文件同步的服务基本上都是用计算文件哈希的方法来确定和对比文件, 这类引起文件哈希变化的硬盘缓存方案还是要慎用.
二进制文件位置带来的自启动问题
因为我习惯用 systemd 做自启动工具，按照 官方文档关于自启动的介绍, 只需要将解压官方 tar 包后得到的 .service 文件复制到 load path 就好了。大概会用到几个命令.
wget https://github.com/syncthing/syncthing/releases/download/v1.0.1/syncthing-linux-amd64-v1.0.1.tar.gz
注意这里的 release 是绝对地址，日后请自行去 官网 拿到最新地址。下面文件夹名也包含绝对版本号，请自行替换.
tar xvzf syncthing-linux-amd64-v1.0.1.tar.gz cp ./syncthing-linux-amd64-v1.0.1/etc/linux-systemd/system/[email protected] /etc/systemd/system/[email protected]
下面的 @ 后面的用户名替换成自己的用户名，我懒，直接用 root. 遵循最佳实践的请自己新建个用户.
systemctl enable [email protected] systemctl start [email protected]
检查一下状态.
systemctl status [email protected]
一般到这里如果看到绿色的 running 字样就是成功了。但我踩到的坑是，官方 tar 包里带的 [email protected] 文件 设置关于 Syncthing 主程序的运行路径是 /usr/bin/, 而我放到了 /usr/local/bin/. 自然启动不起来.
也即是下载回来的 Syncthing 主程序二进制文件应该 mv 到 /usr/bin 才对.
后续再有坑再补充.
参考文章
syncthing 搭建教程：拥有自己的文件同步服务器，在设备间快速同步文件
本作品采用 CC BY-NC 4.0 进行许可。地址: https://d4v.is/syncthing-bug-log/59/ 转载请注明。