CUBELinux · The Builds to Date

Abstract

This is the running record of the CUBELinux builds: what the system is, what each build added, what the gates proved, and what is still ahead. The first whitepaper documents the design and is left untouched as that design record; this document records the builds, and it is written to be read on its own.

The store lives in the kernel. A coordinate is no longer only a way to name a record but a way to reach one — a lookup is a search over arithmetic addresses. A region is a way to query one: a box is found by seeking to the foot of its key span and reading forward. And as of today the whole path works on the metal: this machine boots CUBELinux, the kernel serves the store, writes are durable, listings return the store's records, and the log that makes writes cheap is now folded on a schedule instead of by hand.

Every number below is measured by a gate, by the test suite, or by a command whose output is quoted. Where something is not proven, it says so.

1. What CUBELinux is now

CUBELinux is a coordinate-addressed operating system. A coordinate is (space, point) — a 32-byte space selector and a 192-bit key produced by a space-filling curve (Morton by default) over three 64-bit axes. Records live at coordinates, not behind names; the space is a hard partition, so cross-space access is structurally impossible from a query. The store is in the kernel, the interface is cube(2), and everything above it is written against that interface — a name, a path, or a mount is a view at the edge, not the substrate.

Today that is a running system rather than a design:

• It boots. 6.19.3-cubelinux0.7+, build #85, is installed and running on the workhorse — bare metal, not a VM. The store driver is built into the kernel (CONFIG_CUBELINUX_STORE=y), registers /dev/cubelinux at boot, and is told which image to serve by the command line: cube_store=/var/lib/cubelinux/store.img, with panic=30 so a fault returns the machine rather than hanging it.
• It is the default now, with the workhorse kernel as the way back. As of 2026-09-23 GRUB's default entry is the CUBELinux entry, named by its explicit id (GRUB_DEFAULT='cubelinux'), and the previous workhorse kernel 6.19.3-cube+ is named as GRUB's fallback — so an entry that will not load hands the machine to the kernel that was there before. What that covers is an entry failing to load (a missing kernel or initramfs), and not a kernel that loads and then faults: panic=30 reboots into the same entry, and the way out of that is the boot menu or grub-reboot gnulinux-6.19.3-cube+-advanced-2a7b1834-83ed-4394-a8ee-816b885b5624. It has booted by default since 2026-09-23: a plain reboot, with nothing armed one-shot, came up on CUBELinux with cube_store= and cube_boot_record=1 both on the command line. A running kernel on this machine is therefore still a question about which boot, and /proc/cmdline is where the answer is.
• It serves its store. A client asks the front-end for a listing and gets the store's records; it writes, and the write is acknowledged only once it is durable in the log. The store on disk carries 69,749 records, in a v4 addressed image, sealed, with the format's own verifier reporting errors=0.
• It maintains itself. A fold — the operation that empties the log into the image — now runs on a daily timer, so the store no longer depends on somebody remembering to fold it.
• It records its own boots. cube_boot_record=1 is on the command line, and it is doing the work: the kernel appended boot=1790189822 device=/var/lib/cubelinux/store.img kernel=Linux version 6.19.3-cubelinux0.6+ … into reserved space 0xFC, classed 0x0080, through the same append() as every other record — the OS storing itself, written by the kernel rather than by a client. It is verified three ways on the box, the way its gate verifies it: the record exists; cube(2) serves it back (a read of that coordinate answers 219 bytes with the mask 0x0080, and the front-end answers the same bytes for the name boot); and userspace finds the same record in the image after the log is folded (cube-image flag-scan for class 0x80 finds exactly one). The userspace marker it supersedes is retired; that marker had also stopped working, answering Function not implemented on a kernel with no cube(2).
• And it is fast where it counts, measured on the box. A coordinate read through cube(2) is 4 µs — the mean of 200 reads against the live store of 70,406 records, worst 11 µs — and a ten-record listing is 15 µs. A durable write is 8.2 ms. Those are not the measurements this record carried before, and the write is the reason: the write path resolved the store's layout by reading the whole device — 100,663,296 bytes — in order to append seventy, which cost 60–131 ms per write and was never gated at all, because the gate timed only reads. It now reads the control block and the log's head. On the read side, the control-block validation, the header, the space table and the log window are held across calls instead of re-read per call, and the validation itself dropped from 4096 bytes to 96: the question every call asks of the control block is one number, and it is in the first 48 bytes of each of the two copies. The unfolded log is capped at 256 KiB and folded from the write path, because every read pays for it — the log's capacity is 50,335,744 bytes, so a full one would have put ~48 MB in front of every coordinate read.

2. Milestones reached

Dated, because a milestone is a thing that happened on a day:

3. The build line

The builds that changed the system's shape, in order:

4. What it does

Stated as capability, so it can be checked against the machine rather than believed:

• Address a record by where it is. cube(2) (syscall #548) puts, gets, deletes and syncs at a coordinate. No path, no name, no inode, and no lookup table between the caller and the bytes.
• Walk a space in bounded batches. CUBE_OP_ENUM returns whole records packed as key(24) | flags(2) | value_len(u32) | value, with a cursor that counts the records already returned. A short batch is not the end; a cursor that stops moving is.
• Ask a question about a region. CUBE_OP_RANGE answers the records of a space inside a box, by seeking rather than scanning. §6 has the numbers, including what the bound costs when the box is not aligned.
• Retrieve by class. CUBE_OP_FLAG_SCAN takes a mask, any or all, and one space or every space.
• Write durably, cheaply. A write is acknowledged once it is durable in the log, not once the image has been rewritten; the image is rewritten by a fold, which is now on a schedule. On this machine a write advances the store's on-disk generation and is visible to the very next listing — 6,164 records, one write, 6,165.
• Survive a kill. Acknowledged writes were shown to survive a SIGKILL (verify-kernel-append), and a torn log entry at the tail is discarded rather than replayed (verify-torn-tail).
• Keep the store sealed at rest, with the records as ciphertext on the device.

5. The store and its interface

control block   two copies, 0x0000 and 0x0800   magic, slot size, active slot, generation
image slot      ×2 (the fold writes the idle one, then flips)
[header 46]                       magic, version, curve, extents, counts
[space table: space_count × 48]   space | first index | records
[index: record_count × 40 (v3) / 42 (v4)]   key | [flags] | value offset | value length
[values: packed, in index order]
log region                        the unfolded writes, drained by a fold

The index is fixed-size and sorted by key, so a reader computes a record's place as index_off + i × INDEX_ENTRY — a coordinate is an address, exactly as claimed. The format is described once, in drivers/cube/cube_format.rs, compiled by the kernel and included by userspace; two descriptions of one format is what once shipped an hour of unsupported-version.

A fold is safe to interrupt, and that is a property of the layout rather than a hope: the image lives in two slots, a fold writes the slot that is not active and then points the control block at it. Observed on this store: active_slot 0 → 1 with image_off 4096 → 25165824, and the log went from 49,280 bytes to 0.

Through cube(2) the operations are the verbs the design always named: PUT, GET, DEL, SYNC (fold), ENUM and SPACES (the bounded cursor walks), RANGE (the region seek) and FLAG_SCAN (by class). Each argument block is versioned by its own size field, so the interface grows by gaining a block rather than by being replaced — the coordinate block is 88 bytes, the walk's own is 64, and the kernel routes on the size it is given.

6. A region is a seek

The operation the address existed for is the region query — the records of a space inside a box — and it landed as a seek rather than a filter.

The key fact is about the curve, not the query:

Monotonicity. If p ≤ q on every axis, then key(p) ≤ key(q).

Under it, a box needs no decomposition at all: its two corner keys bound every key inside it, so the index is binary-searched for the foot of that span and read forward to its head — O(log n + span) instead of O(records). Every candidate is then decoded and tested for membership, because a span is a bound, not the set: keys of points outside the box also fall inside it, and returning them would be wrong.

Monotonicity belongs to a curve, not to the trait. Morton and RowMajor have it; Hilbert does not — it transposes and rotates the axes, so its corner keys say nothing about the keys between them, and seeking on them returns wrong answers. The store gates the seek on the curve, and a curve must opt in; it cannot inherit a bound by accident.

Measured over a 32,768-record space, asking 512-record questions:

The 1.00× is exactness worth naming — for an aligned cube at the origin the span is the box's keys. The 6.99× is the honest cost of a bound: an unaligned box's span covers keys of points outside it, and those are examined and rejected. The 64.00× is the gate working — Hilbert has no span, so it walks.

The gate kernel/verify-range.sh boots the kernel and diffs its answer against userspace's over an unaligned box holding a deliberate trap — a record at (2,7,7), outside the box but inside the span — and the walk is correct only if it examines that record and rejects it.

7. What the gates prove

The gate wall, and what each gate proves. The rows marked today were run on 2026-09-23 — the cost, file-store and syscall gates last against build #85, and the box-side rows against whichever kernel was running when they were taken:

The board names 24 gates; the seven above marked today are the ones whose subject this week's work touched, and running those is the rule rather than sweeping the whole wall. The rest last passed with their subjects unchanged. The workspace suite — the crate tests that underpin all of the above — is 206 passed, 0 failed.

8. Defects the gates caught

Named, because each was found only by running the real thing, and a record that shows only the green is a ledger rather than a record:

• A walk that stopped at its first batch. A short batch is not the end — only a cursor that stops moving is. Caught at 747 of 3,006 records; now the rule the walk's tests are written around.
• An index entry written four bytes short — the value length, against the arithmetic that the index is fixed-stride.
• A store that could be folded exactly once: the second fold read an addressed image with a packed-only reader.
• A walk that never ended (2026-09-23). The batch's seen counter started at the cursor instead of at zero, and it is compared after being incremented — so nothing was ever skipped: every call re-served the space from its first record while the cursor advanced by the records returned. Since the cursor is the walk's only end signal, the walk never ended. A listing looped inside the front-end until the kernel's OOM killer took that process, twice, at about 6.4 GiB of anonymous memory each time — and while it was wedged, its writes failed. Every other path that builds a batch already started the counter at zero; this one was the outlier, and it only shows on an addressed image whose space has unfolded edits, which is precisely the live store and precisely what the earlier gates' packed test store never exercised. Fixed at the cause, bounded in the client so a future defect of the same shape cannot take the machine, and the live gate now fails fast instead of streaming duplicates forever.
• A boot record that was silently never written (2026-09-23) — and no gate caught it. With cube_boot_record=1 on the command line, the kernel's first store operation logged could not read the store to record this boot, and the store held no record in space 0xFC at all: the switch was on and the effect was off. The cause is a credential mismatch, not a store fault. The driver opens the store O_RDWR in the calling process's credential context and caches that handle for the whole boot, while every store client on this machine runs as an unprivileged user and the store image was root:root 0664 — readable by its clients, not writable by them. So the first client to touch the store lost that boot its record; once a root-context caller had opened it, the handle was inherited by every later caller and writes began landing normally. Fixed by giving the image the same group the store's other artifacts already use (chgrp cubelinux, mode unchanged), and the record appeared on the next boot. It belongs in this list precisely because it was not in the gate's: verify-boot-record.sh passes and always did, because in a VM the store is a raw device opened by root inside an initramfs — no unprivileged caller, no user services, no stale clock. A gate that opens the store as root cannot see a defect that only an unprivileged caller can produce. It also exposed a second, independent defect that is still open: ensure_boot_record() claims the boot before it attempts anything, so one transient failure costs a boot its record, with no retry.
• A bench that measured a read it never gave a buffer (2026-09-23) — caught by an impossible pair of numbers. The cost gate timed a coordinate read with a.len = 0: no buffer. On the box that reported 0.000 ms across 200 reads while listing one of the ten records it returns reported 0.015 ms — and a listing is one lookup plus nine more index entries, so it cannot be thirty times slower than the lookup inside it. The reading was an artifact of the call's shape rather than a fast read, and it was flagged instead of published. It also means every read figure quoted from that bench before today was a figure for a call handed no buffer, including the one this record previously carried. Fixed by passing the buffer the loop already had; the corrected box numbers are above. The lesson is the instrument's own: a benchmark that skips part of the operation is a benchmark for the part it skipped.

9. What the future holds

Said plainly, and separated into what is next, what is a decision, and what is not claimed:

Next

• Decide what a write's durability costs. A durable write is 8.2 ms and almost all of it is two fsyncs to ext4 — one for the log entry, one for the control block that counts it. That order is the contract, written down deliberately: entry first, count second, so a crash loses an unacknowledged mutation rather than counting one that is not there. Collapsing the two into one would take a write from 8.2 ms to about 4.3 ms — measured, not estimated: one pwrite+fsync on the store's own filesystem is 4.321 ms, and append's shape, two of them, is 8.630 ms, against 8.202 ms for the whole kernel put — so the write path is fsyncs and almost nothing else. That would weaken the contract, so it is a decision rather than a defect; group commit is the alternative that keeps it. Everything else in the latency budget is closed and measured: a read is 4 µs, the read state is held across calls, and the unfolded log has a ceiling.
• Make the boot record's one attempt a guarantee, and its epoch honest. Both remaining gaps are in the record rather than in the switch. ensure_boot_record() claims the boot before it attempts, so a single transient failure — an unopenable store in the first seconds of a boot, or the full-device read this hook performs for itself — costs that boot its record, silently. And the epoch is whatever the clock said at the first write: this machine's clock arrives stale from a night powered off, so the first record carries a time 40 s early, and on the boot before it the clock was 10h 27m behind. Neither is a limitation of the mechanism; both are decisions to revisit.
• Put the name tier on the same footing. Names, documents and the namespace protocol are a view at the edge; the sampler and its client were brought into the tree today so that the whole stack is built, gated and archived together rather than half of it living in a side workspace.
• Meet the realtime constraint. The design was re-weighted once already by robotics — the first whitepaper's §4.5 records that a control loop bounds latency in a way a data workload never does — and that is the integration this work is aimed at: DULRobotics.com. Nothing in this record claims that constraint is met yet; it is the requirement the order of the work above is chosen to serve.

Decisions, not open items

• The filesystem question is settled. The core interface is the coordinate syscall, not a mount; POSIX, where it is wanted, is an opt-in view at the edge — DESIGN-cube-interface §2 is titled "Why not a mountable filesystem".
• The kill switch is built and rehearsed but deferred. Arming it is a terminal step the owner has put off to a later date, deliberately.

Not claimed

• The root filesystem is not coordinate-addressed. The store is; the root fs on this machine is ordinary, and addressing the root as coordinates is a separate question.
• The store is not yet proven at scale beyond this box. The numbers here are one live store of ~69,700 records plus gated fixtures; nothing in this record is a claim about a larger deployment.

10. Checking this record yourself

Every claim above has a command behind it. On the machine that serves this site's store:

cube-image digest /var/lib/cubelinux/store.img    # version, records, errors
cube-image store-info /var/lib/cubelinux/store.img # generation, active slot, log used
kernel/run-all-gates.sh verify-enum-live.sh        # the box's own store, walked
cargo test --workspace --release                   # the workspace suite

The source is public: the tree, the database work and the kernel are three repositories under cubelinux.com/git, all of them readable anonymously — see the terms. The kernel repository is where cube(2) and the store live; the build line above names the commits that changed its shape.