Files
seaweedfs/sw-block
pingqiu a5c39fde34 G5-5C addendum: inscribe INV-G5-FRONTEND-CAPACITY-FROM-DURABLE-CONFIG
Per architect ruling 2026-04-28 + sw addendum landing at
seaweed_block@a250b52: inscribe new INV in the ledger.

Statement: iSCSI/NVMe externally-visible volume capacity and block
size MUST derive from --durable-blocks × --durable-blocksize when
--durable-root is set, not silently fall back to frontend defaults
(DefaultVolumeBlocks=2048 × DefaultBlockSize=512 = 1 MiB). Without
this plumb-through, a daemon configured for N MiB durable storage
advertises a 1 MiB iSCSI/NVMe LUN and any workload above LBA 256
fails.

Test pointers: cmd/blockvolume/frontend_capacity_test.go (6 tests:
ProductOfBlocksAndBlockSize, RejectsZero, OverflowGuard,
IscsiHandlerCapacity, NvmeHandlerCapacity, FrontendDefaults_
StillReturn1MiB). Source-side: cmd/blockvolume/main.go::
computeFrontendVolumeSize flows into both iscsi.TargetConfig and
nvme.TargetConfig handler.

First introduced: P15 G5-5C addendum (P0 product fix).
Owner layer: host (binary, frontend wiring).
Last verified: 2026-04-28 (G5-5C addendum P0; m01 hardware re-
verification pending QA).
Status: ACTIVE.

Awaiting m01 hardware re-run for full §close ledger update.
2026-04-27 23:19:32 -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