fpsync 已停止维护，不适用于现代 linux 环境；其依赖陈旧 librsync 导致编译失败和运行报错，如 undefined reference、共享库加载失败等。
Fpsync 不是更快的 rsync 替代方案，它早已停止维护，且在现代 Linux 环境中基本不可用。 官方仓库已归档，无更新记录（最后 commit 在 2013 年），依赖的 librsync 版本陈旧，编译失败率高，不支持 SSH 密钥代理、路径通配、exclude 规则继承等常见需求。真要处理超大规模文件同步，得绕开 fpsync，直奔更可靠、可调、有维护的方案。
为什么 fpsync 编译失败或运行报错
常见现象包括：undefined reference to rs_delta_create、librsync.so.1: cannot open shared object file、fpsync: error while loading shared libraries。根本原因是它硬绑定老版本 librsync（librsync 2.x，ABI 不兼容。手动降级系统级 librsync 会破坏其他依赖它的工具（如 rdiff-backup），风险远大于收益。
- 不要尝试
./configure && make && sudo make install强行编译——大概率卡在链接阶段 - 不要从 EPEL 或 AUR 拉取预编译包——多数已下架或标记为 unmaintained
- 即使编译成功，
fpsync的并行模型是“fork 出多个 rsync 进程各自扫子目录”，但不共享连接、不合并变更事件，反而加剧 I/O 和 inode 扫描压力
真正适合百万级文件的替代方案：rsync + parallel
不用新工具，只换用法。核心思路是：让 rsync 只负责传输，把“目录分片”和“并发控制”交给 parallel。这比 fpsync 更可控、更易调试、兼容性更好。
- 先用
find /src -maxdepth 1 -type d | tail -n +2 | parallel -j 8 rsync -a --delete {}/ user@host:/dst/把顶层子目录分发到 8 个 rsync 进程 - 对单个大目录，可用
rsync -a --files-from= 配合 <code>parallel分批提交 - 务必加
--delete-after而非--delete，避免传输中途误删目标端文件 - 禁用
-z（压缩）——现代千兆/万兆网络下，CPU 压缩耗时远高于网络传输耗时
更进一步：lsyncd + rsyncssh 是生产环境首选
如果你需要接近实时、低负载、可监控的大规模同步，lsyncd 比任何“一次性并行 rsync”都更适合。它用 inotify 监控变更，聚合事件后触发一次 rsync，避免每改一个文件就建一次 SSH 连接。
-
delay = 30控制聚合窗口，适合写入频繁但允许 30 秒延迟的场景 -
rsync = { archive = true, compress = false, rsh = "ssh -o ConnectTimeout=5 -o BatchMode=yes" }关键是关闭压缩、启用 BatchMode 避免交互式提示阻塞 - 日志路径
/var/log/lsyncd/lsyncd.log必须提前mkdir -p并chown lsyncd:lsyncd，否则服务启动即退出 - 排除列表用
excludeFrom = "/etc/lsyncd_exclude.lst"，内容写绝对路径匹配项，如/tmp/、*.tmp，不支持正则
真正卡住超大规模同步的，从来不是 rsync 本身，而是元数据扫描开销、SSH 连接建立延迟、磁盘随机读性能。与其折腾一个废弃的 fpsync，不如花十分钟调好 parallel 分片策略，或者部署 lsyncd 配合 SSD 缓存目录 —— 后者在 2026 年的硬件条件下，百万级文件增量同步稳定压在 2 秒内完成。
