【发布时间】：2016-01-06 12:31:32
【问题描述】：
我正在努力让我的 bash 脚本运行分段上传到 Amazon Glacier。我的脚本使用 1Mb (1048576) 部件工作，但是当我尝试增加部件大小时，散列不再匹配 aws glacier 返回的散列。我想增加部分大小，因为我的一些档案可以达到 1Tb 的大小。
例如将部分大小增加到 8Mb（8388608 字节）
$ dd skip=0 count=8388608 if=archive.zip of=archive_chunk.1 bs=1
8388608 字节 (8.4 MB) 已复制，0.0122916 秒，682 MB/秒
（使用 split 而不是 dd 得到相同的结果）
$ openssl dgst -sha256 archive_chunk.1
SHA256(archive_chunk.1)= 8ca94b1f246d334e1576d8067b878d61c3a6b494c953518ce25c3f751c4867aa
上传到 aws glacier 返回
{
"checksum": "e5483ab34e587c69023490cfabe2b04b232890be72c0af43309fd385779184b3"
}
当我设置部件的大小时，我在生成哈希时是否有明显遗漏，或者我是否不正确地拆分文件？我尝试了一系列大小（64Mb=67108864 和 256Mb=268435456），但都无法匹配 aws 哈希。
非常感谢任何帮助！
【问题讨论】：
-
tree hash algorithm 要求从 1MB 块开始计算哈希，而不管部分大小。你有考虑到这一点吗？如果您进行 8 MB 的上传，则必须运行 8 + 4 + 2 + 1 次散列操作来获取每个 8 MB 块的散列。你有考虑到这一点吗？
-
非常感谢您的回复。那么每个单独上传部分的散列必须计算为树散列吗？我的印象是（可能被误导了！）树哈希是在上传结束时从各个部分的所有哈希中计算出来的？我将尝试您的建议，看看是否可以让哈希匹配
-
不，正如您所说，树哈希是在最后计算的 - 但它不是来自上传部分的哈希。它必须针对每个正好 1MB 的块进行计算，无论上传部分大小如何。您的代码适用于 1MB 上传部分，但不适用于其他部分大小，这基本上是巧合，因为您碰巧选择了 1MB 上传部分大小。
-
不应该期望单个上传部分的 openssl dgst 哈希与从该单个上传返回的 aws 哈希匹配吗？ （它适用于 1Mb 块）。需要明确的是 - 这是在我进入最后的树散列步骤之前。
-
我很抱歉...我部分地从内存中操作，自从我编写 Glacier API 代码以来已经有一段时间了。部分树散列是 Glacier 上传的部分大小必须正好是 1MiB 乘以 2 的整数幂的原因之一......所以有效的部分大小是 1、2、4、8、16......每个部分的树哈希，所以是的，openssl dgst 只会同意 1 MiB 块大小。