The store's write path is decided (append a log, fold it into the image at a
checkpoint; DESIGN-cubelinux-write-path.md), and that decision forces the log to
sit right after the image on the device. v1 had no extent and no count — it
walked records until it met zero padding — so a v1 reader would have walked
straight into the log's header and parsed it as a record.
v2 states the image's byte extent and its record count, and this teaches the
kernel reader both:
- v1: walk from a 6-byte header until the trailing zeros, as before.
- v2: walk from a 22-byte header, stop exactly at the declared count, and never
read past the declared extent. A zero frame inside the count is a record, not
padding — which is the ambiguity v1 could not resolve.
- a v2 header whose extent does not cover the header itself is refused rather
than guessed at, and a count that is not met counts as an error instead of
quietly returning a shorter list.
Gate, unchanged in method: the kernel's digest of /dev/vda must equal
cube-image's digest of the same bytes. Passing on all three:
v1 curated 11 records fnv1a64=161113085b1573b2
v1 snapshot 35,318 records fnv1a64=5e20f98455387b08
v2 store 4 records fnv1a64=20ecadb5cdc9c994
CUBELinux build
b54ba34dc0