FroghubMan

Yes, it is open source and licensed under MIT.

您好，确实我们也发现同样的问题。 我也正在复现这样的结果，目前能确定的是commd 和ticket 获取是没有问题的，问题大概率是出现在p1和p2的计算上。 多次计算可以得到一次正确的结果，这样比对计算的中间结果，来确定p1还是p2计算过程出的问题。 是否你可以加入我们，一起找到这个问题。

> > 你好，确实我们也发现了同样的问题。 我也正在复现这样的结果，目前可以确定是命令和票可以得到一次正确的结果，这样比对计算的中间结果，来确定 p1 还是 p2 计算过程出的问题。 是否你可以加入我们，一起找到这个问题。 > > 好的，我在有结论后，会反馈出来。 目前确定是p2的comd_r计算结果。 也可能是p1的11层计算结果错误，但是p2的comd_r结果不一样

> 虽然是错误的结果，但是可以正常上链，就是过不了windowpost sealcid不一样，应该时空证明是过不去的

> @FroghubMan 我认为sealcid不一样的原因是上链的sealcid是错的，这种情况无法恢复。 我也思考过这样的可能性。 这种sealcid不一样的出现概率比较低，而且在这样的sealcid情况下还能通过零知识证明（如果p2计算异常，产生的错误cid，零知识证明会失败）。恢复时候产生的“错误”sealcid是大概率情况下产生的结果。 但是这些还只是猜想，我第一次产生这样问题时候，有10多个扇区在我多次恢复后，偶然同时成功。但是第二次我想要验证猜想时，曾使用过30台机器暴力计算一周，都没有得到正确的sealcid。

We also found the same problem. About 1% of sectors cannot be recovered correctly. The problem has not been identified, but it is suspected that the problem may occur when...

If a small number of sectors cannot be recovered after repeated attempts, it is recommended to terminate as soon as possible.

I am very curious, what kind of zfs failure caused sector data loss?

> The numbers are all in OP ) Miner 1222595 , sector 5785. But also 7370, 13197 for example. In recent days, my worker machines have been very busy. There...

Once an old sector is encountered, it is easy to fail to pull the metadata of the sector. After being separated into two businesses, metadata files can be generated with...