mirror of
https://github.com/rustfs/rustfs.git
synced 2026-07-26 16:28:15 +00:00
Zhengchao An
b41bbe2db4
CompleteMultipartUpload enqueued a normal-priority heal whenever `rename_data` returned a `Some(versions)` signature. But the per-disk signature is produced for every object with <=10 versions, and a healthy quorum reduces to `Some` as well, so the `Option<Vec<u8>>` return value conflated two distinct facts — "a version signature exists" and "the committed replicas need heal". The result: nearly every healthy MPU completion self-enqueued a heal, while >10-version objects (signature `None`) did not — an algorithmic heal amplification on the healthy path (rustfs/backlog#1321). Replace the overloaded `Option<Vec<u8>>` second element of `SetDisks::rename_data` with an explicit `RenameConvergence` classification computed after the write-quorum gate: - AllSuccessIdentical — every attempted disk committed with an identical, known signature (no heal). - PartialCommit — write quorum met but a disk failed/offline; a committed replica is missing or stale (heal). - SignatureDivergent — all committed but signatures diverge, or mix signed (<=10-version) with unsigned (>10-version) disks (heal). - Unknown — all committed, no signature produced (>10 versions); latent divergence is left to the scanner backstop, not self-enqueued. `RenameConvergence::needs_heal()` is the single decision point. The version signature is now only comparison material; it no longer doubles as a heal flag. The old `select_rename_data_versions` / `reduce_common_versions` / `rename_data_versions_key` machinery that carried the conflation is removed. The heal submission in `complete_multipart_upload` moves off the ACK critical path into a detached task: it runs after the object lock is dropped and after the durable `rename_data` commit, survives cancellation of the completion future, and coalesces through the existing bounded / deduplicated / observable heal-channel admission (one submit per degraded completion, at most). A completion cancelled in the narrow window between the durable commit and reaching the enqueue is scanner-backstopped, as is the Unknown (>10-version) case. The PUT path (`object.rs`) binds the second element as `_` and is unchanged. The change is orthogonal to and composes with the #1312 commit fence on the same `rename_data` path (epoch rejection is a commit-gate failure surfaced through `Result::Err`, convergence is a post-commit signal); documented in docs/architecture/unified-object-generation.md. Tests: `classify_rename_convergence` white-box cases cover the full acceptance matrix (healthy 4/4 and 8/8, 3-same-1-divergent, failed/offline disk, no-common-quorum split, >10-version all-success and with-failure, mixed signed/unsigned) and fail on revert to the old "signature exists => heal" semantics. The decision function is tested directly rather than through the process-global heal channel, whose receiver is owned exclusively by the blackbox serial test (init_heal_channel is once per binary). Refs: https://github.com/rustfs/backlog/issues/1321
Architecture Documentation
Durable architecture reference for RustFS: migration guardrails, runtime contracts, boundary rules, and support matrices.
Two rules keep this directory healthy:
- Durable reference only. One-shot implementation plans, task trackers, and PR templates do not belong in the repository — keep them in the issue tracker or your local worktree. When their work closes, delete them rather than archiving them here.
- No copies of other sources of truth. Crate lists come from
Cargo.toml, CI steps from.github/workflows/ci.yml, code structure from the code.scripts/check_doc_paths.shfails the pre-commit gate when a doc here references a file path that no longer exists.
Start here
- overview.md — migration baseline, phase order, core principles
CI-enforced core (required by scripts/check_architecture_migration_rules.sh)
- crate-boundaries.md — dependency direction, PR types, re-export contracts
- runtime-lifecycle.md — startup/shutdown sequencing, readiness guarantees
- readiness-matrix.md — request/dependency behavior, probe semantics
- storage-control-data-plane.md — storage API contracts, control-plane boundaries
- global-state-crate-split-plan.md — remaining global-state owners and split evaluation
- ecstore-module-split-plan.md — ECStore decomposition rules and facade contracts
Contracts & invariants
- placement-repair-invariants.md
- unified-object-generation.md — single per-object generation authority (fencing epoch, transport/encoding/proto/mixed-version contracts)
- runtime-capability-contracts.md
- workload-admission-contracts.md
- background-controller-contract.md
- config-model-boundary-adr.md
- ecstore-layout-boundary.md
- decommission-compatibility.md
Support matrices (release-facing, keep current)
- s3-compatibility-matrix.md
- s3-tables-support-matrix.md
- minio-rustfs-router-compatibility.md
- minio-file-format-compat.md
Inventories & baselines (snapshots that feed migration work)
- global-state-inventory.md
- ecstore-api-facade-inventory.md
- ecstore-config-consumer-inventory.md
- obs-ecstore-dependency-inventory.md
- background-services-inventory.md
- admin-route-action-snapshot.md
- compat-cleanup-register.md
Historical plans and trackers (rebalance/decommission phases, migration-progress ledger, and the one-shot migration snapshots that fed it — startup timeline, scheduler baseline, profiling/NUMA capability inventory, KMS development defaults inventory) were retired in 2026-07 once the architecture-review ledger they served closed out (backlog#660/#665). Planning documents are no longer kept in the repository.