mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-20 13:30:46 +02:00
pingqiu
4045f8c8aa
Single doc per v3-batch-process.md §2: scope + acceptance + invariants + forward-carry + risks + sign table; §close appended at batch close (no separate kickoff / closure / G-1 docs). Scope: m01 hardware first-light, promoting G5-4's L1 (binary composition) result to L3 (Replicated IO) per v3-architecture.md §13: 1. iterate-m01-replicated-write.sh orchestration script 2. Real iSCSI write byte-equal primary→replica on hardware 3. iptables disconnect + engine-driven catch-up (within retention) 4. 10x -race stress on G5-4.5 integration test (m01 has CGO/gcc) Architecture touchpoints (v3-architecture.md): §6.1 Write Path, §6.3 Replication Path, §7 Recovery Explicit non-claims: rebuild path, NVMe target, durability modes, failover, backend-layer failure injection — all defer to follow-up batches per §1. Forward-carry consumed (G5-4 §close criteria 3+4+6). G-1 N/A (V3-native verification batch, no V2 muscle PORT). Per v3-batch-process.md §15: per-agent action list at end.
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