mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-11-10 05:48:19 +01:00
pingqiuandClaude Opus 4.6
edec7098e8
Adds sw-block/ directory with:
- distsim: protocol correctness simulator (96 tests)
- cluster model with epoch fencing, barrier semantics, commit modes
- endpoint identity, control-plane flow, candidate eligibility
- timeout events, timer races, same-tick ordering
- session ownership tracking with ID-based stale fencing
- enginev2: standalone V2 sender/session implementation (63 tests)
- per-replica Sender with identity-preserving reconciliation
- RecoverySession with FSM phase transitions and session ID
- execution APIs: BeginConnect, RecordHandshake, BeginCatchUp,
RecordCatchUpProgress, CompleteSessionByID — all sender-authority-gated
- recovery outcome branching: zero-gap, catch-up, needs-rebuild
- assignment-intent orchestration with epoch fencing
- design docs: acceptance criteria, open questions, first-slice spec,
protocol development process
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
162 lines
3.1 KiB
Markdown
162 lines
3.1 KiB
Markdown
# V2 Open Questions
|
|
|
|
Date: 2026-03-27
|
|
|
|
## Purpose
|
|
|
|
This document records what is still algorithmically open in V2.
|
|
|
|
These are not bugs.
|
|
|
|
They are design questions that should be closed deliberately before or during implementation slicing.
|
|
|
|
## 1. Recovery Session Ownership
|
|
|
|
Open question:
|
|
|
|
- what is the exact ownership model for one active recovery session per replica?
|
|
|
|
Need to decide:
|
|
|
|
- session identity fields
|
|
- supersede vs reject vs join behavior
|
|
- how epoch/session invalidates old recovery work
|
|
|
|
Why it matters:
|
|
|
|
- V1.5 needed local reconnect serialization
|
|
- V2 should make this a protocol rule
|
|
|
|
## 2. Promotion Threshold Strictness
|
|
|
|
Open question:
|
|
|
|
- must a promotion candidate always have `FlushedLSN >= CommittedLSN`, or is there any narrower safe exception?
|
|
|
|
Current prototype:
|
|
|
|
- uses committed-prefix sufficiency as the safety gate
|
|
|
|
Why it matters:
|
|
|
|
- determines how strict real failover behavior should be
|
|
|
|
## 3. Recovery Reservation Shape
|
|
|
|
Open question:
|
|
|
|
- what exactly is reserved during catch-up?
|
|
|
|
Need to decide:
|
|
|
|
- WAL range only?
|
|
- payload pins?
|
|
- snapshot pin?
|
|
- expiry semantics?
|
|
|
|
Why it matters:
|
|
|
|
- recoverability must be explicit, not hopeful
|
|
|
|
## 4. Smart WAL Payload Classes
|
|
|
|
Open question:
|
|
|
|
- which payload classes are allowed in V2 first?
|
|
|
|
Current model has:
|
|
|
|
- `WALInline`
|
|
- `ExtentReferenced`
|
|
|
|
Need to decide:
|
|
|
|
- whether first real implementation includes both
|
|
- whether `ExtentReferenced` requires pinned snapshot/versioned extent only
|
|
|
|
## 5. Smart WAL Garbage Collection Boundary
|
|
|
|
Open question:
|
|
|
|
- when can a referenced payload stop being recoverable?
|
|
|
|
Need to decide:
|
|
|
|
- GC interaction
|
|
- timeout interaction
|
|
- recovery session pinning
|
|
|
|
Why it matters:
|
|
|
|
- this is the line between catch-up and rebuild
|
|
|
|
## 6. Exact Orchestrator Scope
|
|
|
|
Open question:
|
|
|
|
- how much of the final V2 control logic belongs in:
|
|
- local node state
|
|
- coordinator
|
|
- transport/session manager
|
|
|
|
Why it matters:
|
|
|
|
- avoid V1-style scattered state ownership
|
|
|
|
## 7. First Real Implementation Slice
|
|
|
|
Open question:
|
|
|
|
- what is the first production slice of V2?
|
|
|
|
Candidates:
|
|
|
|
1. per-replica sender/session ownership
|
|
2. explicit recovery-session management
|
|
3. catch-up/rebuild decision plumbing
|
|
|
|
Recommended default:
|
|
|
|
- per-replica sender/session ownership
|
|
|
|
## 8. Steady-State Overhead Budget
|
|
|
|
Open question:
|
|
|
|
- what overhead is acceptable in the normal healthy case?
|
|
|
|
Need to decide:
|
|
|
|
- metadata checks on hot path
|
|
- extra state bookkeeping
|
|
- what stays off the hot path
|
|
|
|
Why it matters:
|
|
|
|
- V2 should be structurally better without becoming needlessly heavy
|
|
|
|
## 9. Smart WAL First-Phase Goal
|
|
|
|
Open question:
|
|
|
|
- is the first Smart WAL goal:
|
|
- lower recovery cost
|
|
- lower steady-state WAL volume
|
|
- or just proof of historical correctness model?
|
|
|
|
Recommended answer:
|
|
|
|
- first prove correctness model, then optimize
|
|
|
|
## 10. End Condition For Simulator Work
|
|
|
|
Open question:
|
|
|
|
- when do we stop adding simulator depth and start implementation?
|
|
|
|
Suggested answer:
|
|
|
|
- once acceptance criteria are satisfied
|
|
- and the first implementation slice is clear
|
|
- and remaining simulator additions are no longer changing core protocol decisions
|