对于健康的旧对象,持久的 MRF 部分写入意图不会释放

持久 MRF 部分写入意图对于健康的旧对象不会进行清除 ## 摘要 在 RustFS de484b93e(一个节点,四个本地磁盘,EC 2+2)上,持久 MRF 部分写入积压持续存在,没有前台写入或活动扫描器。后台修复管理器队列保持在 9,000 个正常优先级 MRF 任务附近。对一个抽样目标进行范围内深度修复后,所有四个驱动器都显示为 ok,但返回了 未知 的结果,因为对象使用默认的旧分片格式。持久 MRF 日志在重复尝试和服务重启后保持不变。下面的主机名、卷路径、存储桶名称和对象键被省略或概括。 ## 观察结果 - 在成功完成完整扫描周期(7 小时 26 分钟)后,修复队列仍然接近 9,000。扫描器随后被设置为 24 小时周期。 - 重启 RustFS 将 healQueueLength 从大约 9,000 减少到 5,137,但仅持续了一段时间。在扫描器处于非活动状态时,它在一分钟内恢复到大约 9,000。 - 签名的 POST /rustfs/admin/v3/background-heal/status 响应显示 queuedBySource.mrf = 8,999, 所有都是 normal 优先级;其他所有排队源均为零。有一个 MRF 任务处于活动状态。 admission.full 和 admission.merged 在没有前台写入的情况下迅速增加。 - 在所有四个磁盘上的相同磁盘 buckets/.heal/mrf/journal-scoped.bin 快照中包含 16,409 个 CRC 有效记录。所有记录都是范围内、未版本化的 PartialWrite 意图;16,406 个记录引用应用程序对象,三个记录引用内部元数据。快照在重启时被写入,并在管理器循环通过目标对象时保持字节级别不变,持续了 25 分钟以上。 - 三个可通过 S3 HEAD 可见的应用程序目标。一个 568 字节的抽样目标在所有四个磁盘上都有对象元数据和数据目录。使用 recreate=false, remove=false 的范围内管理员深度修复完成,但其原始结果具有 disposition.state = "unknown", bucketIncarnationId = null, poolIndex = null 和 setIndex = null。其项目详细信息为: 旧对象使用标准修复;独立对象身份仍未验证。 重启前和后的驱动器状态均为 ok;没有任何字节被修复。 - 重启后没有出现新的修复警告或错误。队列依然保持空闲。 ## 需要调查的源级解释 默认的 RUSTFS_SHARD_INTEGRITY_WRITE 和 RUSTFS_SHARD_INTEGRITY_FLEET_CONFIRMED 值均为 false(crates/config/src/constants/object.rs)。在 crates/ecstore/src/set_disk/ops/heal.rs 中, integrity_verified 需要一个受保护的对象; metadata_verified 也需要保护或删除对象。对于一个健康的旧对象,深度修复因此不会产生 VerifiedHealthy 回执。 crates/heal/src/heal/storage.rs 在没有验证完整性或元数据的情况下返回没有对象回执。 crates/heal/src/heal/manager/scheduler.rs 仅发布一个 Repaired, VerifiedHealthy 或可靠地不存在的对象结果的 MRF 验证修复事件。 …