8 Commits

Author	SHA1	Message	Date
overtrue	c20fe73d6f	fix(ecstore): fence stale rebalance workers	2026-08-22 12:34:24 +08:00
cxymds	e11fcfbd08	fix(rebalance): converge multipart data movement retries (#6057) ... * fix(rebalance): converge multipart data movement retries * fix(rebalance): harden multipart retry replacement * fix(rebalance): isolate internal multipart uploads * test(ecstore): adapt metadata mutation fixtures * fix(rebalance): preserve transition metadata semantics * refactor(ecstore): reuse internal metadata matcher * Revert "refactor(ecstore): reuse internal metadata matcher" This reverts commit c87ca0328f. * refactor(rebalance): reuse data movement log constants * fix(rebalance): isolate migration-owned state * fix(rebalance): preserve pre-gate retry compatibility	2026-08-13 06:12:26 +00:00
cxymds	f5463f4aa8	fix(rebalance): defer changed source cleanup (#5829)	2026-08-08 10:45:34 +08:00
cxymds	b301588248	fix(rebalance): drain entry tasks before listing retry (#5820) ... * fix(rebalance): drain entry tasks before listing retry * test(rebalance): satisfy clippy in retry regression	2026-08-08 05:50:47 +08:00
Zhengchao An	98d3619613	fix: address rc.1 release blockers (#5648) ... * fix: address rc.1 release blockers * fix: route release guards through architecture boundaries * fix: close remaining rc.1 regression gaps * refactor: group multipart listing options * fix: resolve rc.1 CI regressions * fix(ecstore): keep bucket-config writes off the caller's stack A bucket-config write nests incarnation resolution (which can drive legacy migration and a peer fan-out), a full metadata load, and `save` — itself an object PUT that pulls in the whole erasure write path. Every request that mutates bucket config is already several futures deep, so inlining all of that into one state machine overflows the 2MiB worker stack in debug builds. Two CI lanes aborted with SIGABRT on this: ILM Integration (serial) rustfs app::lifecycle_transition_api_test:: compensation_driven_complete_multipart_upload_still_transitions Test and Lint (swift) rustfs-protocols::swift_metadata_persistence:: swift_metadata_writes_are_durable Neither test file is touched by this branch and both lanes are green on main. Stack-pointer probing showed ~780KiB consumed between `metadata_sys::update` and the config read alone, with single hops of 363KiB (`update` -> `acquire_config_write_guard_for_incarnation`), 125KiB and 105KiB. Box the deep sub-futures on both read-modify-write paths (`update` / `update_checked` and `update_config_with` / `update_config_with_checked`) so each guard's own state machine stays small. Behaviour is unchanged; `update` -> guard drops to 253KiB and both tests pass on the default stack. * fix(lifecycle): unbreak restore under the bucket generation fence The ILM lane aborted on a stack overflow before reaching these, so they were never reported; with that fixed, four restore tests fail. All four are green on main and none of their test files are touched by this branch. 1. RestoreObject and ListMultipartUploads hard-required `opts.expected_bucket_incarnation_id`, but `apply_bucket_generation_guard` deliberately leaves it unset when no guard extension is present — only the S3 access layer installs one. Every direct caller therefore got `InternalError: ... bucket generation guard is missing`. Resolve the current generation instead, the way the copy path already does. The fence is unaffected: RestoreObject still re-reads the incarnation from disk and compares before admitting the restore, and the multipart listing is filtered by the value it resolves. 2. `restore_expiry_snapshot_matches` (new on this branch) rejected every restored-copy expiry whose `restore_expires` had not already elapsed. Whether the restored copy is due to expire is the ILM evaluator's decision, made when it emitted DeleteRestoredAction; re-deriving it in the set layer only adds a way for a legitimate action to be rejected. The stale-event risk it appears to guard is already covered by the surrounding snapshot match — a re-restore rewrites `restore_expires`, so a replayed event fails the equality check. Drop the clause; the fifteen identity clauses are unchanged. Fixed: rustfs app::lifecycle_transition_api_test:: restore_object_usecase_accepts_exactly_one_of_two_concurrent_restores restore_object_usecase_completes_suspended_null_version_in_place restore_object_usecase_reports_ongoing_conflict rustfs-scanner::lifecycle_integration_test serial_tests:: test_restore_chain_local_read_expiry_keeps_remote_and_allows_re_restore Verification: the CI ILM lane filter now runs 53/53 green locally. * chore: address review follow-ups on this branch Four items from the adversarial review that were still open. - Restore the assertion `test_bucket_replication_replayed_delete_marker_ preserves_source_mtime_without_source_restart` is named for. The branch had replaced the backlog#867 mtime check with `assert_replication_ converged`, which any successful replication satisfies, and deleted the two helpers it needed — so the regression the test exists to catch would now pass. This matters here specifically because the branch changes the flag feeding `replication_delete_remove_options` and routes replay through a new file and ordering. - Drop `read_config_no_lock_preserve_empty`: zero production callers (the one real consumer calls the `_with_metadata` variant directly). Its test stanza now exercises that variant, so the coverage moves to live code rather than being deleted. - Revert the `bytesize` bump. It is a no-op: `Cargo.lock` already pinned 2.7.0 before this branch and is untouched, so the caret range already resolved there. Nothing in the diff uses the crate. - Split the AGENTS.md "Adversarial Validation" policy change out of this branch. The edit is defensible on its own, but it relaxes the review gate that this branch has to pass, so it should land as its own PR reviewed on its own merits rather than bundled with the change that benefits from it. The reverted hunks are unchanged and ready to re-apply. Not changed, deliberately: the missing-sidecar path still fails closed. `missing_bucket_incarnation_sidecar_for_new_metadata_fails_closed` pins that on purpose, and serving a non-authoritative Object Lock state would be the wrong trade. The residual concern stands and is recorded in review — a crash between the two writes in `persist_new_and_set` leaves the bucket unloadable until DeleteBucket+CreateBucket, and the repair branches in `migrate_legacy_metadata` and `make_bucket` are unreachable dead code for that case. Resolving it needs the read path and the (transaction-lock holding) repair path to be separated, which is more than a follow-up edit. * test(ci): serialize the new bucket-incarnation tests The five tests this branch adds around the incarnation / lifecycle fence drive `init_bucket_metadata_sys` and `bucket_metadata_sys_of` — process-global OnceLock state that `serial_test`'s `#[serial]` cannot protect across nextest's process boundary — and they delete+recreate buckets, the shape that raced into InsufficientWriteQuorum in backlog#937. Add them to the `ecstore-serial-flaky` group in both the default and ci profiles (nextest evaluates a named profile's own overrides list, so the ci mirror is required). Preventive serialization only, no retries. Not a full fix for the review comment: `bucket_delete_waits_for_config_ mutation_fence` still proves liveness with a fixed 200ms sleep plus `assert!(!delete.is_finished())`. Turning that into readiness polling needs a production-side signal to wait on — asserting "still blocked" is inherently a negative. Serializing the group removes the parallel-load pressure that makes the window fragile; the sleep itself is left for a follow-up. * test(ecstore): pin that a drained bucket is actually deletable `DeleteBucket`'s emptiness check is `has_xlmeta_files`, a raw scan of the bucket directory on local disks — not an S3-level listing. So "the client drained the bucket" and "the bucket is deletable" are two different contracts, and only the first one was covered. That gap is what the `S3 Implemented Tests` lane is failing on: 219 cases, all `BucketNotEmpty` on `nuke_prefixed_buckets`, with every test body passing. The first one is `test_versioning_obj_suspend_versions`, reported by pytest as PASSED followed by ERROR at teardown. Add the missing assertion for the unversioned path: PUT, client DELETE, then assert no `xl.meta` survives and `DeleteBucket` succeeds. It passes — which is itself a result: the plain delete path leaves no residue, so the s3-tests failure is not there. The versioning-suspended path is the remaining suspect (the client DELETE leaves a null delete marker, and draining means purging it by `versionId=null`). It is not covered here: `BucketVersioningSys` resolves through the ambient `get_bucket_metadata_sys()` OnceLock, which this unit env cannot set, so the bucket never actually reports as suspended. That repro belongs at the e2e layer where a real server owns the versioning state. * fix(ecstore): let an explicit null-version delete purge its delete marker Root cause of the `S3 Implemented Tests` lane: 219 cases, all `BucketNotEmpty` on `nuke_prefixed_buckets`, every test body passing. On a versioning-suspended bucket a client DELETE leaves a null delete marker — correct S3 semantics, and an `xl.meta` on disk. Draining the bucket therefore means purging that marker as `?versionId=null`, which is what `nuke_bucket` does before `DeleteBucket`. That purge was rejected: explicit null-version purge of the null delete marker must succeed, got [Some(MethodNotAllowed)] so the marker survived, and `DeleteBucket`'s emptiness check — a raw `has_xlmeta_files` scan of the bucket directory, not an S3 listing — kept reporting the bucket as non-empty. The two sides of the version comparison in the batch delete loop are in different namespaces. `goi.version_id` is the client-facing identity, where `from_file_info` synthesizes `Some(Uuid::nil())` for a null version on a versioned *or versioning-suspended* bucket. `version_id` is the storage identity, where `delete_file_info_version_id` maps an explicit `?versionId=null` to `None`. Comparing them raw makes the purge look like a version mismatch, so `explicit_delete_marker` is false and the `MethodNotAllowed` from the lookup is recorded as a delete failure. This only became reachable on this branch: previously `check_opts` did not carry `dobj.version_id`, so `set_disk_delete_creates_delete_marker` was true, `object_lock_check_required` was false, and the lookup that produces `MethodNotAllowed` never ran. Adding the version id to `check_opts` lit up a comparison that was already wrong. Normalize both sides through `delete_file_info_version_id`. The regression test injects a real Suspended bucket-config snapshot — the delete path reads versioned/suspended from that snapshot, not from `opts`, so without it `from_file_info` never synthesizes the null version id and the branch is not reached. Mutation-checked: restoring the raw comparison fails the test with the exact `MethodNotAllowed` above. * fix(app): drop the now-needless struct update Reverting `crates/replication` to main removed the extra `MrfReplicateEntry` fields, so this literal specifies every field again and `..Default::default()` trips `clippy::needless_update` under `-D warnings`. Caught by CI, not locally: I had run `cargo check --workspace --all-targets`, which does not see clippy-only lints. Ran `cargo clippy --workspace --all-targets -- -D warnings` here — clean. * test(e2e): assert the fresh-volume classification four_node_empty_legacy_volumes_start_as_fresh only started the cluster and listed buckets — no assertion, so any classification path that still permits startup left it green without proving the pre-created empty `.minio.sys` directories were treated as fresh volumes. Pin what that classification actually leaves behind: no buckets adopted into the namespace, `.rustfs.sys/format.json` written on every drive, and the empty legacy directory left untouched rather than migrated into. * fix(bucket): apply the requested Object Lock to existing buckets Site replication replays make-with-versioning against the destination, carrying the source's `lockEnabled`. When the destination bucket already exists it takes `force_create`, and the whole option-application block was gated on `confirmed_missing` — so the call returned success while the replica stayed unlocked. Replicated versions could then be deleted without the retention the source enforces. Object Lock enable is one-way, so applying it to an existing bucket is safe: move it out of the creation-only gate, keeping `created` and versioning-only options creation-scoped as before. An existing authoritative bucket takes the `cache_bucket_metadata_in` branch, which only caches, so the enable would have been dropped on restart. Persist instead when the enable actually changed something. Mutation-checked: restoring the creation-only gate fails the new `force_create_enables_object_lock_on_an_existing_bucket` with "Object Lock must be enabled on the existing bucket". cargo nextest run -p rustfs-ecstore --lib: 3633 passed. * fix(ecstore): box the generation-checked config mutation paths too The earlier stack fix boxed `update` and `delete`, but an authorized bucket-config mutation carrying an incarnation takes `update_if_incarnation` / `delete_if_incarnation` instead — which were still inlining the whole resolve/load/save chain into an already-deep request future. Same overflow, sibling path. * fix(restore): keep the nil-version normalization the strip removed Reverting the replication subsystem to main took `set_disk/replication.rs` with it, but one line in that file was this branch's own fix rather than replication work: - self.version_id.filter(|v| !v.is_nil()) == fi.version_id.filter(|v| !v.is_nil()) + self.version_id == fi.version_id For a versioning-suspended object the expected version is `Some(Uuid::nil())` while the read-back `FileInfo` carries `None`, so the raw compare reports every suspended restore as "restored object changed before restore metadata finalization" and the copy-back never commits. Same nil-vs-None mismatch as the null delete-marker purge fixed earlier on this branch. Caught by `Test and Lint (rio-v2)`, not by my local runs: the test lives in `transition_commit_failure_tests`, gated behind `feature = "test-util"`, so the 3633-test suite I had been running never included it. Re-ran with `--features rio-v2,test-util`: 3722 passed.	2026-08-03 19:25:43 +00:00
houseme	399461c33e	fix(ecstore): bound listing walks by drive stall, not total duration (#4647) ... Foreground S3 listings wrapped the entire walk_dir stream in a single wall-clock timeout (RUSTFS_DRIVE_WALKDIR_TIMEOUT_SECS, default 5s). That budget measured how much data the walk had to produce rather than whether the drive was still answering, so a healthy but large prefix on slow media returned 500 InternalError / "Io error: timeout" to the client. The timer also kept running while the walk was blocked writing to a slow consumer, charging merge-side backpressure to the producer. WalkDirOptions::stall_timeout_ms already carried the right semantics but was only honored by the remote-disk RPC walk; LocalDisk::walk_dir ignored it entirely. A single-drive deployment therefore had no way to distinguish a hung drive from a big directory. Teach LocalDisk::walk_dir to bound each individual drive read with the stall budget, defaulting it from RUSTFS_DRIVE_WALKDIR_STALL_TIMEOUT_SECS when the caller does not pin one, and let the foreground listing path skip the wrapper-level total timeout. A walk that keeps making progress now runs to completion; a drive that stops answering still fails with DiskError::Timeout. Time spent blocked on the consumer stays outside the budget. Heal and rebalance walks already skipped the total timeout and previously ran unbounded on local drives. Give them an explicit, generous 60s stall budget so this change does not tighten them from "no bound" to the 5s default. Fixes #4644 Refs #2999, #3001 Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-10 12:20:54 +08:00
houseme	0866a8e6a0	fix(ecstore): route rebalance delete markers to store and count lifecycle expiries (#4540) ... fix(ecstore): route rebalance delete markers to store and count expiries Rebalance migrated delete markers via SetDisks::delete_object (single set, no cross-pool routing), which silently rewrote the marker back onto the source set. The subsequent source cleanup then deleted the whole entry, losing the delete marker and reviving logically-deleted objects (#942, P0). Route delete-marker migration through ECStore::delete_object via a store- level closure that mirrors the existing transfer closure, so the marker lands on the cross-pool target honouring data_movement/src_pool_idx/ delete_marker; on failure it is not counted as moved, so the source entry is not cleaned up. The unused MigrationBackend::delete_object_for_migration footgun is removed. Rebalance source cleanup also ignored lifecycle-expired versions: the gate used rebalanced == total_versions and passed an empty allowed_missing, so any entry with an expired version could never be cleaned up, leaking the migrated versions in the source pool (#950). Mirror decommission: gate on rebalanced + expired == total_versions and feed expired version identities into the cleanup preflight allowed_missing, plus a source_retained warning for parity with decommission diagnostics. Adds regression tests for delete-marker store routing and the expiry-aware cleanup gate. Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-08 17:45:54 +00:00
Zhengchao An	0a5b1b1b3a	refactor: consolidate ecstore owner module layout (#3934) ... * refactor: shrink ecstore root owner facades * refactor: remove ecstore core store root shims * refactor: move ecstore erasure owner modules * refactor: remove ecstore root rpc facade * refactor: move ecstore services domain modules	2026-06-27 09:03:20 +08:00