我有3太字节，超过300,000个各种尺寸的参考文件（每个20,30,40,200兆），我通常会定期备份（不是拉链）。几个月前，我丢失了一些文件可能是由于数据降级（正如我所做的那样＃34;备份＆＃34;损坏的文件，恕不另行通知）。
我不关心安全性，所以不需要MD5，SHA等。我只是想确保我复制的文件是好的（相同的位和字节）并验证备份是否完整几个月后再次进行备份。
因此，我的需求是基本的，因为文件不是很重要，不需要安全性（没有敏感信息）。 我怀疑：格式/方法＆＃34; SFV CRC / 32＆＃34;对我的需求是好还是快？还有更好更快的东西吗？我使用的是ExactFile程序。
是否有比SFV / CRC32更快的校验和，但这没有缺陷？我尝试使用MD5，但它很慢，因为我不需要数据安全性，我更喜欢SFV / CRC32。但是，它很痛苦，因为有超过300,000个文件，并且需要几个小时来制作所有这些文件的校验和，即使使用CPU xeon 8核心HT和快速HDD。
从数据完整性的角度来看，将一个.ZIP或.RAR中的所有文件加入而不是让它们＆＃34;松散＆＃34;在文件夹和文件中？
一些提示？
谢谢！
答案 0 :(得分：0)
如果你可以量化“几个月前的”少数“和”一些“，我丢失了一些文件”（其中“少数”将被视为被“每隔几个”取代以获得费率），然后你可以计算出假阳性的概率。但是，从这些话来说，我会说，是的，32位CRC应该适用于您的应用程序。
至于速度，如果你有一个最近的英特尔处理器，你可能有一个CRC-32C指令，可以使计算速度提高大约15倍。（某些代码请参见this answer。 ）通过在多个核上运行它可以更快地完成。如果做得好，您应该受到I / O的限制，而不是计算。
在这种情况下，将它们用拉链或rar捆绑是没有优势的。事实上，如果一个文件的损坏导致你失去一切，情况可能会更糟。
答案 1 :(得分：0)
如果您没有获得每个核心每秒至少250 MB的吞吐量，那么您可能需要I / O或内存速度限制。 CRC32和MD5的原始散列速度高于此值，即使在数十年前的硬件上也是如此，假设实现非合理的优化实现。
查看Crypto++ benchmark，其中还包含大量其他哈希算法。
Castagnoli CRC32可以比标准的CRC32或MD5更快，因为较新的CPU有一个特殊的指令;使用该指令和大量支持代码（用于并行散列三个流，将部分结果与一些线性代数拼接在一起，等等。）你可以将散列加速到大约 1个循环/ dword 。由于特殊的AES指令，基于AES的哈希在最近的CPU上也很快。
然而，最后哈希函数等待读取数据的速度并不重要;特别是在多核机器上，你几乎总是在这样的应用程序中进行I / O绑定，除非你被小缓存和深存储器缓存层次结构的延迟所破坏。
我坚持使用MD5，它不比CRC32慢，并且普遍可用，即使是在最古老的机器上，几乎每种编程系统/语言都发明过。不要把它想象成'加密安全散列'（它不是，不再是），而是作为某种CRC128，它与CRC32一样快，但需要一些2 ^ 64的散列才能使碰撞成为可能，而不是像CRC32那样只有几万个。
如果你想推出一些自定义代码，那么CRC确实有一些优点：可以通过将子块的CRC与一些线性代数组合来计算文件的CRC。使用像MD5这样的一般哈希是不可能的（但你总是可以并行处理多个文件）。
有大量现成的程序可用于计算文件和目录的MD5哈希快速。我推荐md5sum + cousins的'深层'版本：md5deep and hashdeep，您可以找到on SourceForge和on GitHub。
答案 2 :(得分：0)
正如你所说，我的问题是硬盘驱动器。对于备份和存储，我使用三个Seagate，每个2 TB（7200rpm 64兆高速缓存）。使用SSD时，程序会快得多，但使用数TB的文件很难使用SSD。
几天前，我在部分档案中执行了该程序：1 tera（约170,000个文件）。 ExactFile花了大约六个小时来创建摘要SFV / CRC32。我使用了我的一台新机器，配备了i7 4770k（嵌入了CRC32指令，8核 - 四个真实和四个虚拟，MB Gygabyte Z87X-UD4H，16个RAM）。
在整个文件计算过程中，CPU内核几乎无法使用（3％到4％，最多20％）。硬盘是100％使用的，然而，只有他的速度功率的一小部分（sata 3），大部分时间70 MB / s，有时下降到30 MB / s，具体取决于计算的文件数和反病毒在后台（我后来禁用了，就像我在复制大量文件时经常做的那样）。
现在我正在测试使用二进制文件比较的复制程序。无论如何，我将继续使用md5摘要。感谢信息，欢迎任何提示。