Files
seaweedfs/sw-block
pingqiuandClaude Opus 4.6 ded84b25e6 refactor: Batch 4 steps 2+3 — rebuild status port + recovery bundle factory
Step 2: Rebuild completion status port
- New runtime.RebuildCompletionStatus + DeriveRebuildCommitted:
  reusable shaping logic for post-rebuild snapshot → RebuildCommitted event
- block_recovery.go OnRebuildCompleted: delegates to DeriveRebuildCommitted,
  host only reads raw snapshot via readRebuildStatus (thin binding)
- Removed 15 lines of inline flushedLSN/checkpointLSN/achievedLSN computation

Step 3: Recovery bundle factory
- New buildRecoveryBundle: shared host-side setup for both catch-up and rebuild
  (creates Reader + Pinner + StorageAdapter + Executor + RecoveryDriver)
- runCatchUp and runRebuild both use buildRecoveryBundle instead of
  duplicating the WithVolume → NewReader → NewPinner → NewStorageAdapter →
  NewExecutor → RecoveryDriver chain
- runCatchUp/runRebuild are now thin host-shell methods

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-04 01:32:34 -07:00
..

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-block product structure clean enough to split into a separate repo later if needed

Suggested layout:

  • design/: shared V2 design docs
  • prototype/: 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 inside seaweedfs
  • likely future state: sw-block becomes a standalone sibling repo/product
  • design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths