# K1676–K1680 checkpoint ordering

This fixed disposable fixture has three metadata home sectors (120, 128 and
136), a log at 112, a commit at 113 and a checkpoint at 114. Each home contains
the corresponding 16-byte journal payload followed by zero bytes. The complete
homes must be written and flushed before writing and flushing the checkpoint.
Only then can commit and log be cleared and flushed. Early recycling returns
an error without I/O; an I/O failure makes that object terminal.

The checkpoint retains the three-record journal, sequence and a CRC32. Remount
compares the entire expected checkpoint and all three home sectors. A valid
checkpoint with mismatched homes is rejected. A surviving commit or log during
retirement is distinguishable from complete recycling.

The commit check covers its marker, sequence and journal CRC. The inherited
data-digest field is opaque here; this fixture does not validate file data or
define a complete data/metadata allocation layout.

Host tests inject failures at every one of the nine write/flush operations and
check two persistence endpoints: loss of all unflushed writes, and survival of
all completed writes. They do not exhaust arbitrary torn writes or every subset
of reordered persistence.

Guest acceptance requires three separate QEMU processes per RAM/boot profile:
apply and flush homes while retaining the commit; restart and repeat application,
flush the checkpoint and retire the log; restart again and mount the clean
state without writes. The first process ends between completed operations; this
does not simulate loss of a physical device's power or an in-flight torn write.
Device traces and exact whole-disk snapshots must agree at every transition.

This is a bounded development experiment. General mounts, concurrent writers,
durable ring allocation, physical power-loss guarantees and product acceptance
remain open.