我经常使用Unison在需要用户工作的工作站之间同步用户的主目录。 不幸的是，随着公司的发展，Unison在决定哪些文件发生了变化时变得越来越慢。 实际转移所花费的时间相比可以忽略不计。
同步在星形拓扑中完成，以RAID-6统一服务器为中心。 有些工作站使用Windows（NTFS），一些Linux使用Ext-4或BTRFS（！）。
在编写本文时，有一个用户，其主目录是45GB大，100K文件，完全同步时间约为30分钟。 请注意， find >null简单目录遍历需要2分钟左右的时间。
有什么策略可以进一步加快这个过程？ （除了减less要同步的文件数量）我相信在理论上可以加快Unison，但是fastcheck选项是不够的。
好的，我find了罪魁祸首：unison会忽略xls和mpp文件的fastcheck选项，并且始终对它们进行完整的比较。 它是这样做的，因为Excel习惯于修改xls文件而不更改上次修改date。
不幸的是，对于我们来说， xls使文件大约占整个文档量的20％。
在hex编辑器中编辑/usr/bin/unison ，并用不太可能find的东西（比如xxx ）来代替xls 。
在Unix文件系统（btrfs，ext4）中，这个过程应该是安全的，因为文件的任何改变都会改变inode的编号，如果可以的话unison应该使用这个信息。 至于基于NTFS的客户端，我认为我们应该忍受这个缓慢的时间…或者有其他的select（放弃Excel或者改变文件系统）。
在这次黑客攻击之后，联盟加速了十多次！