我经常使用 Unison 在用户预期工作的工作站之间同步用户的主目录。不幸的是，随着公司的发展，Unison 在确定哪些文件已更改时变得越来越慢。相比之下，实际传输所花费的时间可以忽略不计。
同步是在星型拓扑结构中完成的，中心是 RAID-6 统一服务器。一些工作站使用 Windows（使用 NTFS），一些使用 Linux（使用 Ext-4 或 BTRFS(!)）。
在撰写本文时，有一位用户的主目录有 45GB，包含 100K 个文件，对他来说，完全同步时间大约需要 30 分钟。请注意，简单的目录遍历大约需要 2find >null分钟。
有哪些策略可以进一步加快这一进程？（除了减少要同步的文件数量）我相信理论上 Unison 可以加快速度，但选项fastcheck还不够。
答案1
好的，我找到了罪魁祸首：unison 确实忽略了和文件fastcheck的选项，并始终对它们进行完整比较。它这样做是因为 Excel 习惯于修改 xls 文件而不更改上次修改日期。xlsmpp
不幸的是，xls这些文件的大小约占整个文档容量的 20％。
在十六进制编辑器中编辑/usr/bin/unison并替换xls一些不太可能找到的东西（如xxx）就可以了。
在 Unix 文件系统（btrfs、ext4）中，此过程应该是安全的，因为文件的任何更改都应更改 inode 编号，并且 unison 应该使用此信息（如果可用）。至于基于 ntfs 的客户端，我认为我们应该忍受缓慢的时间……或者也许有一些替代方案（放弃 Excel 或更改文件系统）。
经过这一下破解，齐声速度加快了十倍不止！