我正在寻找一种有效的方法来通过慢速传输介质部分检查“大型”数据集的完整性。这似乎是一个常见的问题，因为文件大小的增长与传输速率不成比例。
例如，对于具体数字，USB2 上的 TB 数据。通过将每个字节读入哈希或校验和来检查此数据是否仍然有效需要一天时间，并且会增加驱动器故障的风险。
相反，此代码需要验证随机数据片段，并根据可用时间提供有效性概率。如果允许运行足够长的时间，将验证所有 block (读取整个数据集的基本情况)。
用法“故事”:
-- 数据存储在大型加密容器中(大小为 1TB .. 1GB)。
-- 每个容器在不同位置的多组驱动器上进行冗余备份。
-- 必须在不知道底层数据或 key 的情况下进行验证检查。
该方法需要检测哪些故障模式:
- 存储传输故障(例如， Controller 丢弃部分物理地址)
- 扇区错误(没有为特定 block 返回数据)
- 单位错误(非 ECC 内存或缓存)
检测到错误时，将从冗余存储中恢复数据。验证数据可能必须单独存储。
由于目标是数据完整性，来自文件共享网络的技术似乎并不适用——“哈希树”需要在每个节点完全存储哈希值，这似乎比需要的存储量更多没有主动攻击者的场景。
- 如何权衡存储空间与读取文件相关 block 的时间？
- 如果哈希树/哈希列表是最好的方法，那么存储哈希的部分值有多安全？
- 对于等效保护，某些校验和或纠错码是否是比散列更好的选择？
最佳答案
传输是通过 USB2 进行的，对吗？因此你应该知道:
- USB 通信以数据包的形式进行，有效负载高达 1024 字节以进行高速传输和 16 位 CRC。
- 每个数据包都得到确认并可能重新传输。
您必须考虑这些信息以部署一种算法，该算法在 CRC 提供的保证之上添加一些保证，否则将是徒劳的。如果我没记错的话，16 位 CRC 可以检测到任何不长于 16 位的单个错误突发以及更长的一小部分。
您可以从维基百科开始:http://en.wikipedia.org/wiki/USB2和 http://en.wikipedia.org/wiki/Cyclic_redundancy_check .
关于algorithm - 概率文件验证——算法还是库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/312175/