mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-15 18:48:32 +02:00
pingqiuandClaude Opus 4.7
6d8d088273
Closes QA round-2 feedback loop. Three concerns resolved and one L2-blocker hazard added. ## Q1-Q3 resolution (sw-verifiable per QA concern; V2 source check) Q1 scope completeness: VERIFIED complete. V2 grep shows sync_all_* are three test files only — `sync_all_adversarial_test.go`, `sync_all_bug_test.go`, `sync_all_protocol_test.go`. Zero production files for sync_all / split_brain / takeover / arbiter. These are cross-entity invariants, not distinct types. 10-entity set stands. Q2 ReplicaReceiver scope: VERIFIED per-volume, not per-assignment. `v.replRecv = recv` at `blockvol.go:1515` is the only write site; zero `replRecv = nil` assignments in codebase. Receiver is constructed-once per BlockVol instance. L1 §2.3 wording stands. Q3 RebuildSession/Bitmap durability: VERIFIED no sidecar. Grep `rebuild_bitmap.go` + `rebuild_session.go` for `os.Open / os.Create / WriteFile / ReadFile / persist / sidecar` → empty. Recovery is WAL hydration only (`hydrateBitmapFromRecoveredWAL` at `rebuild_session.go:102`). L1 §2.10 invariant #3 CORRECTED — earlier draft incorrectly called out a "sidecar schema" that doesn't exist. ## QA concern #3 resolution: §3.14 new hazard `AllBlocks()` semantic divergence: V3 `walstore.go:565` and `smartwal/store.go:367` both call `s.Read(lba)` which reads through the dirty map (includes unflushed WAL bytes). V2 `rebuild.go:handleExtentStream` uses `readBlockFromExtent` which BYPASSES dirty map (flushed-only). Concrete impact: V3 base stream can contain bytes the primary hasn't fsynced. If primary crashes pre-fsync, replica's copy is "newer" than primary's recovered state. Epoch fencing + WAL-wins bitmap still prevent corruption, but the invariant chain is "eventually consistent via epoch churn" instead of V2's "base stream never contains unflushed bytes". Different contracts, same end state. Two L2 options proposed: (a) keep AllBlocks semantics + document non-claim in §2.7 bridge; (b) add `LogicalStorage.AllBlocksFlushed()` preserving V2 invariant. H5 architect-line decision affects which path is safer. ## QA concern #2 resolution: §3.a locked-pairs section (new) Documents pre-coupled L2 decisions driven by V3 existing shape: H6 Option C → H7b locks automatically (Provider intercepts at LogicalStorage layer; Backend.Write stays host-facing, doesn't carry LSN) §3.14 + H5 → AllBlocks safety rationale depends on which H5 shape wins Per BUG-005 documentation-discipline lesson: record coupled pairs explicitly rather than leaving them as "implied". Saves L2 cycles and gives future readers visible intent for why Backend.Write excludes LSN. ## QA concern #1 deferred to L2 Volumes map extension (single-map with role discrimination vs two separate primaryHandles + replicaHandles maps) is a legitimate L2 design concern. L1 appropriately hedges with "likely needs to grow" (§3.11 Option C); L2 picks shape. QA's BUG-005-adjacent concern (role-discriminated handle callers forgetting to check role) is the right frame for the L2 decision. No L1 edit needed; flagged for L2 attention. ## §4 open questions status Q1-Q3 ✓ resolved Q4 DistGroupCommit residence → effectively answered by §3.11 C Q5 protocol-frame wire-compat stance → still architect-line (pairs with H5) Blocking L2 start now: only H5 + Q5, both architect-line. QA to draft one-page arch memo per round-2 offer. ## Change log §5 feedback-round log gains round-3 entry §6 change log gains full round-3 detail with V2 line citations Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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