之前同学的NAS积累了大量的素材，总量当初超过64T，现在已经超过100T，因为考虑到有很多文件重复，希望可以帮忙去重来节省点空间。

2017年年底那时候的想法是通过全文Hash记录每个文件的Hash，组建一个DB，之后每加入一个文件，算Hash然后跟DB比对，如果Hash一致再进行全文对比。尺寸、创建/修改时间可以拿来作为前置条件可以避免Hash耗时。

前些天想到可以改进Hash，比如Fib级数对4K * Fib(n)采样，大小可以是4K，组成一个小型的摘要再进行Hash，这样几乎不耗时，可以作为全文Hash的替代。毕竟如果能通过这个摘要的对比，极大可能是一致的，可以作为高度疑似重复文件留给人工判定或者异步全文比对服务进行后续处理。之前也想过利用随机算法取，或者按照固定步长，前段时间做Zine的系统设计面试任务，其中一个要求是要用到Fib级数，所以联想到了。从Stackoverflow上看到也有人提到这个问题，另外看到这篇文章觉得作者对于文件末尾部分的考虑也是不错的想法，作者开头也提到了原来有专门的工具dedup。

今天上午电用完了，没电就想着怎么做一些不用网的事，然后就想到这个事情了，然后把NAS连上，分别抽取了size > 1,000,000,000字节的文件，很惊奇find的效率真是高只用了4s钟就扫完了，这样我就更细化了，分别降到了200 * 10^6字节和100 * 10^6字节，100m的情况也是只用了不到1分钟。对100m+的这些文件做了统计，总大小85873187310546折合79T，uniq后得到极限重复量23507845634932折合22T，全NAS存储量101T，所以很巧合又是一个2/8原则：

全存储量 (T) 大于100m (T) 小于100m (T) 大文件占比例
101 79 22 78.22%

另一个：

全存储量 (T) 大文件重复上限 大文件占比例
101 22 21.78%

为了弄这个查了find、cut、sed命令，觉得也可以学习一些人的每天一个Linux命令系列。

update 2019-05-16 08:16

刚刚看到这篇文章，对于重复了如何处理问题，符号连接大约是大家公认的方案