mirror of https://github.com/rustfs/rustfs.git synced 2026-10-27 06:18:43 +00:00

Files

T

唐小鸭 741de6f81c fix(replication): locate encrypted replicas without comparing ETags (#8602 )

Since 1.0.2 an encrypted object's ETag is a keyed fingerprint, not the
plaintext MD5. A target that computes its own ETag (AWS S3, Wasabi) never
reports it, so every "find the existing replica by exact ETag" step missed
encrypted objects on targets that mint their own version ids:

- a heal / MRF re-drive after a lost PUT response wrote a second version;
- an existing-object resync re-PUT a replica its ledger already named
  (the ledger-located HEAD was confirmed by ETag only), and on the AWS
  400 shape the ledger was not consulted at all;
- resync verification counted such replicas as failed;
- a ledger-less version purge reported the replica as already gone.

Encrypted sources now recognise their replica by shape: the byte count the
replication PUT sent (plaintext for managed SSE, ciphertext for SSE-C) and
a target write time no earlier than the source version. An ETag match
still wins (RustFS/MinIO targets). The ledger is consulted first on both
the 404 and the AWS 400 shape. Without a ledger, only a unique shape match
among the unclaimed ListObjectVersions candidates is adopted and recorded;
several shape matches mean re-PUT for convergence and a refused purge. The
AWS current-version fallback stays ETag-only, and a listing the
target refuses on the 400/403 shape keeps that fallback (re-PUT) rather
than stalling. An unversioned target's `null` version is never matched by
shape: it holds whichever generation was written last. Plaintext sources keep exact
ETag identity.

Builds on the ETag-computing fake target mode and the ComputesOwnEtags
matrix row from rustfs#8583. Adds an SSE-S3 variant of the mint-own-ids
re-drive test (red before this change: the heal left two target versions),
and both variants now also assert the purge.

2026-10-16 13:44:33 +08:00

architecture

fix(heal): recover replacements after pool removal (#8600 )

2026-10-16 12:08:29 +08:00

operations

fix(replication): locate encrypted replicas without comparing ETags (#8602 )

2026-10-16 13:44:33 +08:00

postmortems

fix(replication): send an integrity header on Object Lock PUTs (#7097 )

2026-09-03 20:26:44 +08:00

testing

test(replication): cover SSE-S3 replicas on ETag-computing targets (#8583 )

2026-10-16 00:07:54 +08:00

README.md

fix(quota): keep writes available with a degraded fleet (#8604 )

2026-10-16 13:05:20 +08:00

README.md

Documentation

Use the focused indexes rather than treating this directory as an unordered collection:

Operations

Table maintenance periodic queueing — opt-in scheduling, limits, worker handoff, and recovery.

For PUT cleanup admission, blocking-pool isolation, and optional CPU affinity, see PUT cleanup isolation.

External certificate issuance and TLS rotation — publication, native reload, trust separation and failure handling.
Architecture guard troubleshooting — diagnose repository guard failures.
Logging governance — broad event audits, migrations, and guardrail changes.
Multipart upload memory diagnosis — allocator attribution, Docker reproduction and sustained upload checks.

For the logical per-operation io_uring read cap, see io_uring read chunk size.

For bounded local read-backend startup and cancellation, see io_uring backend initialization.

For legacy protection assessment and bounded protected copies, see Object integrity inventory, audit, and migration.

For encrypted listing compatibility and older stored fingerprints, see Encrypted object ETags.

For durable hard quota accounting, node-outage behavior, and fence protocol upgrades, see Durable hard quotas.

Operational runbooks live under operations/. Replication operators should start with:

Runbook	Use it for
Site replication operations	Health fields, pending operations, outage recovery, re-pair admission, IAM/SSE boundaries, and upgrades.
Replication target check	Validating an S3 destination and version fidelity before enabling replication.
Replication object size limits	Multipart routing, large-object limits, and retry characteristics.
Replication outbound transport	Integrity headers, generic target behavior, and transport knobs.

For the erasure-coded cluster lifecycle (planning, parity and EC:0, expansion, rebalance, decommission, heal, drive replacement, restart recovery, and the rc CLI mapping), start with Cluster and erasure-coding lifecycle operations.

For concurrent bucket creation and deletion, see Bucket operation admission.

For persisted administrator bucket tasks and bucket recreation, see Bucket heal recovery.

For interrupted object deletions and returning drives, see Delete transaction recovery.

For disk replacement across VM restarts and schema 5/6 maintenance migration, see Replacement generation recovery.

For historical GET timeouts during PUT or Heal, see Object lock contention diagnostics.

Other runbooks remain grouped by filename in operations/; architecture pages link to the relevant runbook where a cross-boundary procedure is required.

For storage dashboards, see Storage metrics and observer selection: drive ownership, snapshot freshness, counter queries, and rolling upgrades.

For per-bucket capacity and object counts, see Bucket usage metrics: OTLP export, cluster deduplication, accounting semantics, and scanner freshness.

For optional shard commitments, see Independent shard integrity rollout: activation, legacy repair results, multipart mode changes, and rollback limits.

For crates.io publication of workspace crates, see Workspace Cargo Publish: dependency ordering, dry-run, publish, and failure handling.