记录下 Resilio Sync 的一个坑

[Sylv]

TL;DR

Resilio Sync 在差异同步下仍会重写整个文件，在用于同步类似日志文件这样不断变动的文件时，会导致巨量硬盘写入量。

起因

前几天我无意中使用 DriveDx 查看硬盘 S.M.A.R.T. 信息时发现，我使用了差不多才一年的 MacBook Pro 的 SSD 硬盘写入量竟然高达 180 TB ！按 365 天算，平均每天写入量接近 500 GB。

非常不可思议，因为我并没有主动写入这么多数据量。虽然 MacBook Pro 的 SSD 应该有相当高的写入寿命，但按这疯狂的写入量趋势，我还是怕没过一两年这 SSD 就得出问题。

很快我就通过 iStat Menus 和活动监视器（ Activity Monitor ）发现，造成这疯狂写入量的罪魁祸首就是 Resilio Sync。Resilio Sync 持续不断地以数十 MB/s 的速度往硬盘写入数据，一天的写入量可以达到 1 TB 以上，但是我并没有使用 Resilio Sync 同步这么高的数据量。

我的 Resilio Sync 使用场景

大半年以来，我有二三十台服务器长时间在跑我的一个程序，我一直用 Resilio Sync 来同步这些服务器上此程序使用的配置文件和生成的 CSV 数据文件以及日志文件到我的电脑上，这样可以很方便地管理和维护这么多台服务器，也可以及时获取生成的数据文件，一直都挺满意的。

虽然同步的服务器多，但需要同步的数据量并不高，每台服务器上同步的文件夹总大小一般只有几百 MB，而程序每分钟只会新增几十行数据到 CSV 数据文件和日志文件中，因为 Resilio Sync 支持块级差异同步——只有文件新改动的部分才需要传输，所以几十台服务器总共一直也只有 KB/s 数量级的同步量，一天应该不到 1 GB 的数据量。

那么按这同步量，理论上 Resilio Sync 一天的写入量也只要 1 GB 左右就好了，但是实际上 Resilio Sync 却以上千倍的速度不断地往硬盘写入数据，导致一天能有上 TB 的写入量，和同步量严重不符。

原因

为了找出造成此问题的具体原因，我搜遍了互联网没找到先例，以及尝试了许多现在看来是徒劳的方法，期间的折腾就按下不表，最终被我发现导致这问题的原因是：

Resilio Sync 虽然支持差异同步传输，但是在同步到差异数据后会重写整个文件！

假设服务器上有个 100 MB 的文本文件，之前已经和本地同步好了。现在在文件末尾添加了 1 MB 的数据，Resilio Sync 可以只传输这新增的 1 MB 数据到本地，但是本地在接收到这 1 MB 后，会读取已有的 100 MB 文件加上这 1 MB，重新写一个 101 MB 的文件覆盖原文件，而不是将新的数据直接写入原文件。每次同步完后文件的 inode 编号都会改变，说明文件已经不是同一个文件了，我是这样才发现的。

所以虽然我的同步量很少，但是服务器上生成的数据文件和日志文件有的能涨到上百 MB 大小，而且每分钟都会有新增数据，因此 Resilio Sync 在同步过程中就会不断重写这些大文件，也就导致了每天上 TB 的恐怖写入量。

解决方法

受制于 Resilio Sync 的这个机制，在我这使用场景下其实并没有可以根治的办法，可能 Resilio Sync 就不适合用来同步这种一直会变动的文件，但我目前没找到更好的替代方案。

我唯一能做的就是改程序，将生成的数据文件和日志文件按时间或者大小进行拆分，使得需要不断同步的文件的体积保持在一定大小以下，以此来减少每次重写的数据量。这样更改后效果还是很明显的，Resilio Sync 每天的写入量从 1 TB 多降低到了 100 GB 左右，减少了 90%，虽然和实际同步量比还是很高，但已经在我可接受范围内，再配合上 Resilio Sync 的定时暂停同步功能，可以进一步降低写入量，这样应该在这台电脑淘汰前不会因此导致 SSD 提前寿终正寝了。

收到了 Resilio Sync 支持的反馈回复，简而言之这个问题是 Resilio Sync 目前的同步机制导致的，和存档功能（Archive）有关：

当更新同步文件的时候，原文件会先被复制到 .sync 子目录（因此产生了重写），然后在那里对文件副本进行更新，接着再把更新后的文件替换回原文件，而原文件则会被移到 .sync/Archive 目录进行存档（如果开启了这功能）。

因为是软件设计的机制所导致的弊端，所以估计暂时是无解了，不过回复有说会考虑改进这部分。

Thank you for contacting us. Resilio Sync can detect an updated file piece and can sync that only. However, it cannot patch the file itself, so it copied the file to .sync, patches it there and moves back to its place. The original file is moved to .sync/Archive. That's how it's coded to work now. We'll see to improve this part.

[kawowa]

按时间分片，超过 n 天的归档，这是好文明

[Volekingsg]

rclone ？

[Sylv]

@Volekingsg 确实有考虑过 rclone，不过就得自己写定时同步脚本了，还是 Resilio Sync 简单方便而且有 GUI，暂时不打算折腾了。

[LU35]

@Sylv 可以试试同样功能的开源 syncthing

[zuoakang]

resilio sync 适合同步不频繁变动的冷数据

[silvernoo]

@LU35 #4 syncthing 有增量同步吗？

[abbottcn]

syncthing +1

如果有不区分大小写的文件系统参与，请确保文件名不要出现大小写问题。

[ScotGu]

早年间 被 resilio sync 坑过一次，当然也不排除是我智商不足。把我的工作日志搞得支离破碎，更新后一个同步变回档。
现在用 OneDrive，美滋滋。

[xmi]

可以向官方反馈一下 看能不能改进

[gamexg]

@ScotGu #8 我被 OneDrive 折腾的很惨，编辑中代码就被回档为旧版本了，文件变更后 ide 还自动重新加载；另外从未修改的文件还被拷贝了多个版本。


我觉得这个应该是故意设计的，
目的应该是防止其他程序访问到变更中的文件。

[Sylv]

@xmi 已反馈，不过我估计不会理我，网上都没其他人抱怨这个问题。

[Sylv]

@gamexg 你这么说貌似有道理。

[sujin190]

还有一个问题也挺坑的，如果你用其他方式已经下载回来部分文件，这时候添加整个文件夹同步，发现并不会认为已经存在文件传送成功而是重新传送，坑死了

[sujin190]

@xmi 这个设计太扯了吧，文件分块传输，每块索引难道不是一开始就算好了？后续直接比较索引写入就可以了，怕什么本地同时修改，如果本地修改双向同步的话应该同步到远程啊，中间并不需要一直打开文件吧

[Sylv]

@Livid BTSync 2016 年更名为 Resilio Sync，节点应该改名了。

[wanguorui123]

mbp 是 MLC 的 SSD，不用担心寿命问题