mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-28 18:55:49 +00:00
Addresses QA's 3 notes + 1 clarification ask: Note 1 (role inference): §1.3 rewritten — fact.ReplicaID is master-minted (proto verified at control.proto:128-148 + mint site at services.go:198-205). Binary reads `fact.ReplicaID == self.ReplicaID` directly. No lex-smallest fallback (master always names exactly one bound replica per volume per line). Removes the binary-side authority inference that violated the master-authority rule. Note 2 (acceptance circular): §4 #2 verifier reframed to G5-4.5 in-process test. m01 hardware verification belongs to G5-5; G5-4 closes on the in-process pin. Note 3 (G5-DECISION-001 contradiction): §5 rewritten — G5-4 ships Path B runtime AND keeps Path A serializability seam open. T4d-4 part B's RoundTripJSON test already pins serializability; G5-4 preserves it. G5-6 architect ratification can promote to Path A by adding persistence on top of the existing struct, with no engine-state-shape change. Clarification ask (sessionID minting): §6 added INV-BIN-WIRING-SESSIONID-VIA-ADAPTER. Adapter mints unique sessionIDs via process-wide atomic counter at adapter.go:70; binary inherits for free as long as it dispatches via the adapter (never via framework shortcuts that hardcode sessionID=1, which is the known T4c §I + QA G5-1 round 1 SKIP gap). Pinning this invariant keeps the gap test-side. Re-submitted for QA re-review per parent kickoff §7 governance loop.
sw-block
Private WAL V2 and standalone block-service workspace.
Purpose:
- keep WAL V2 design/prototype work isolated from WAL V1 production code in
weed/storage/blockvol - allow private design notes and experiments to evolve without polluting V1 delivery paths
- keep the future standalone
sw-blockproduct structure clean enough to split into a separate repo later if needed
Suggested layout:
design/: shared V2 design docsprototype/: code prototypes and experiments.private/: private notes, phase development, roadmap, and non-public working material
Repository direction:
- current state:
sw-block/is an isolated workspace insideseaweedfs - likely future state:
sw-blockbecomes a standalone sibling repo/product - design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths