block subsystem: a flush rewrites the whole BAM -- 24 MiB each way now the stick's BAM is sized for 256 GiB #155

Open
opened 2026-11-08 12:55:12 +00:00 by rajames · 0 comments
Owner

Should -- for a ruling (Captain Bob). Found building #92 Task 2; recorded in docs/fabric/FABRIC-3.md XLVIII.9.

What

blk_flush() (v3/src/block_subsystem.c) calls bam_flush_to_disk() each time it writes back a dirty block, and bam_flush_to_disk() reads every BAM page from the disk and writes every one back. Attach (bam_sync_from_disk()) reads every page too.

Since #92 Task 2 the stick's and the data stick's Artemis are formatted with a BAM sized for the 256 GiB growth cap (R1; mkartemis --bam-for): 6144 devblocks, 24 MiB. So each flush of a dirty disk block reads 24 MiB and writes 24 MiB over USB, where the 2 GiB Artemis's own BAM was 35 devblocks (about 140 KiB). Attach reads the 24 MiB once.

Nothing in acceptance flushes a disk block, so it does not show there; a v4 block saved to Artemis (v4/system/blocks.c: blk_update + blk_flush) would.

Recommended

Read and write only the BAM pages that hold the volume's user blocks (bits up to BLK_DISK_SYS_RESERVED + user_blocks): the pages past them are never changed by a flush, so the bytes on disk are the same and v3's behaviour is unchanged. Better still, write back only the pages a flush changed.

It is shared v3 code, so it was not changed without a ruling.

Test

A v4 session that saves a block to Artemis on the grown stick, timed before and after; the BAM's bytes on disk identical either way.

**Should** -- for a ruling (Captain Bob). Found building #92 Task 2; recorded in `docs/fabric/FABRIC-3.md` XLVIII.9. ## What `blk_flush()` (`v3/src/block_subsystem.c`) calls `bam_flush_to_disk()` each time it writes back a dirty block, and `bam_flush_to_disk()` reads **every** BAM page from the disk and writes every one back. Attach (`bam_sync_from_disk()`) reads every page too. Since #92 Task 2 the stick's and the data stick's Artemis are formatted with a BAM sized for the 256 GiB growth cap (R1; `mkartemis --bam-for`): **6144 devblocks, 24 MiB**. So each flush of a dirty disk block reads 24 MiB and writes 24 MiB over USB, where the 2 GiB Artemis's own BAM was 35 devblocks (about 140 KiB). Attach reads the 24 MiB once. Nothing in acceptance flushes a disk block, so it does not show there; a v4 block saved to Artemis (`v4/system/blocks.c`: `blk_update` + `blk_flush`) would. ## Recommended Read and write only the BAM pages that hold the volume's user blocks (bits up to `BLK_DISK_SYS_RESERVED + user_blocks`): the pages past them are never changed by a flush, so the bytes on disk are the same and v3's behaviour is unchanged. Better still, write back only the pages a flush changed. It is shared v3 code, so it was not changed without a ruling. ## Test A v4 session that saves a block to Artemis on the grown stick, timed before and after; the BAM's bytes on disk identical either way.
rajames added this to the v4.0.0-alpha.4 milestone 2026-11-08 12:55:13 +00:00
Sign in to join this conversation.