Swift/ec 批准指针想法
目录
EC “approval pointer” 想法
历史：我们最初称之为 manifest，但在完善这个想法后，认为这个名字不好。现在它被称为 “approval pointer”。好好享受吧。
问题
Paul：这是 ec_hashes pickle 的替代方案
- 应该将哪一组 EC 碎片视为要维护的持久版本？
- 我们如何知道哪些碎片可以被清理？
- 是否可以针对小对象 EC 进行优化？
当代理从写入碎片存档中获得足够的成功信号后，它就知道要在系统中维护的碎片集合，并写入 “approval pointer” 数据（即告诉一组对象服务器写入该数据）。
什么是 “approval pointer” 对象？
- 它是一个对象（零大小）
- 它在系统中被复制。
- 它包含一个时间戳和一个 UUID，该 UUID 唯一标识要维护的碎片存档集合。
- 一个时间戳标记，表示“在这个时间点，存在一个持久的 PUT”
为什么存储一个 UUID 来引用一组碎片存档？
- 它消除了（磁盘上）在 [部分] 重写情况下的名称冲突
- “approval pointer” 更新是原子性的，并且仅在 EC 写入成功后才完成。
- 时间戳本来就不同。UUID 允许 FA 存储在与 “approval pointer” 不同的节点上
“approval pointer” 存储在哪里？
- 选项 1：存储在与碎片存档相同的节点上（作为单独的磁盘文件）
- 存储在磁盘目录树中
- /mnt/part/suff/hash/ts.data
- /mnt/part/suff/hash/uuid/ts.data
- 存储在磁盘目录树中
- 选项 2：在系统中存储 3 次（无论副本计数是多少）
- 像普通对象一样存储
重构器呢？
选项 1（在 FA 旁边）：<-- 不会产生那么多重构器网络使用量
重构器找到一个 FA，然后检查本地 ec “approval pointer”。如果 “approval pointer” 引用与 FA 相同的 UUID，那么在本地一切正常，可以继续检查整个 EC 对象是否正确……
如果 “approval pointer” 引用不同的 UUID，那么重构器需要比较 “approval pointer” 和本地 FA 的时间戳。如果本地 FA 的时间戳较旧，则可以删除本地 FA。如果本地 FA 的时间戳比 “approval pointer” 更新，那么只能在经过一段时间后（一周？）才能删除它。
选项 2（3 次 “approval pointer” 副本）：<-- 可能会用于小对象优化
这与选项 1 相同，除了 _存在_ 查找 “approval pointer” 数据的网络操作。如果存在本地副本，可以使用本地副本 “approval pointer”。
难题：<-- 这仅适用于选项 2，并且您使用它来解决小对象问题。我们如何在相同的策略中存储 3 次副本和 14 路 EC？两个环？14 路环的某个子集？
强烈建议
使用选项 1（将 “approval pointer” 与每个碎片存档一起存储），稍后再解决小对象 EC 优化问题。
优化
- 如果我们弄清楚选项 2 在 “approval pointer” 存储的位置，那么我们就有了一个很好的位置来添加小文件优化。
- 将 “approval pointer” 数据存储为元数据？
- 将 “approval pointer” 存储为指向 uuid 目录的硬链接？
- 在 GET 路径上，对象服务器不返回 0 字节的 “approval pointer”，而是返回引用的 FA。如果没有本地 “approval pointer”，则继续返回最新的 FA。如果正确的（引用的）FA 不存在，对象服务器可以返回 404。对象服务器仍然需要返回其他可用的时间戳。
