mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-20 13:30:46 +02:00
pingqiuandClaude Opus 4.7
ce78fea36f
Per QA infra-check round 2026-04-26, surfaces real readiness gaps before architect ratifies G5-4 schedule: m01 (192.168.1.181 — primary node): ✅ 32-day uptime; sudo password-less; 16 cores; 19 GiB RAM ✅ 177 GiB free disk; Go 1.26.2 installed ✅ iptables / netns / multi-process tools all available ✅ T2 m01 NVMe script template available as pattern reference M02 (192.168.1.184 — replica node): ✅ Reachable from m01 (0.92ms); same kernel; 178 GiB free disk ❌ Go NOT installed — must scp binaries from m01 Implication for G5-4: Build binaries on m01, scp to M02. Same cross-node binary pattern T2 already uses for its iSCSI target deployment. G5-4 skeleton at seaweed_block/scripts/iterate-m01-replicated-write.sh implements this build-then-scp flow. No infrastructure blockers. Architecture ready as soon as G5 mini-plan ratifies scenario list. 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