0.2 read the store. This appends to it: a mutation through /dev/cubelinux is
written to the log and fsynced *before* the write is accepted, which is the
kernel's version of the contract cube_duratest.py proves for the daemon.
- the mutation comes in as the argument block the coordinate interface will
pass: op(1) | space(32) | x(8) | y(8) | z(8) | len(4) | value[len]. The kernel
Morton-encodes the point itself — a key written here has to be the key a
userspace reader decodes, and that is a thing the gate would catch if it were
merely similar;
- the append lands after the log's valid prefix, so a torn tail is overwritten
rather than appended to, exactly as the userspace log does it;
- a log region that has never been written is zeros, not a log: the header is
written first, the way the userspace log creates its file;
- the entry's CRC covers space, key, length and value, computed the same way.
The write is the byte plane — bytes at a coordinate, no header written beside
them — because that is what a differential comparison against userspace's
`cell put` can be exact about. The header tier sits above this.
Gate (kernel/verify-kernel-append.sh), four mutations including an empty value
and a record in a second space:
reference : bytes=500 records=6 value_bytes=94 fnv1a64=6b679d39597a62b3
kernel : bytes=500 records=6 value_bytes=94 fnv1a64=6b679d39597a62b3
folded : bytes=500 records=6 value_bytes=94 fnv1a64=6b679d39597a62b3
survived : bytes=500 records=6 value_bytes=94 fnv1a64=6b679d39597a62b3
The third line is the one that matters: userspace *reads the log the kernel
wrote*, folds it, and lands on the same store. Without it the first two would
only show the kernel agreeing with itself. The fourth is a SIGKILL of the VM
with no shutdown and therefore no flush for us.
Not yet: the kernel folds nothing itself, so it still depends on a userspace
checkpoint to reclaim its log. That is the next step, and it has its own gate.
CUBELinux build
93e2c8c39b