aboutsummaryrefslogtreecommitdiffstats
path: root/docs/research/076-one-sync-commit.md
Commit message (Collapse)AuthorAgeFilesLines
* Record why the remaining store ideas waiteunhhu2026-09-261-3/+16
| | | | | | | | | | | The zero tail wrote as many bytes as the commits under 64 writers, yet turning it off changed nothing beyond the SD card's own noise and made 8 writers wait longer, so it stays until faster storage is measured. Overlapping a sync with the next burst would win a few percent at most. The second sync of a new process's first commit is rare with one owning server. The larger lever is write amplification: a 16-byte edit rewrites its whole leaf and catalog path.
* Make a tree store commit durable with one synceunhhu2026-09-261-0/+144
A commit used to sync its nodes, then write the head and sync again: the order of writes was forced by syncs. Now the head carries where the commit's bytes start and their digest, and one fdatasync makes the bytes and the head durable together. A crash during it can leave a head whose bytes did not all reach the device; its digest then fails and the older slot stands, which is safe because a writer only builds on a durable head. Commits overwrite written zeros kept after the published end, so the sync changes neither the size nor the block map and needs no journal commit. On the SD card this is 2.4 ms per commit against 9.1 ms for two syncs; the store commits 289-304 times a second instead of 94-109, and pure-serve answers 2,012-2,611 durable PUTs a second against 583 for crash-safe axum. A process remembers the heads it published or checked, so it reads a commit's bytes at most once and never its own. Its readers pass over the head it is still making durable and so never answer with a commit a crash could take back. Head slots get a block each and the format becomes PURETRE2; a handle's refresh reads the slots through its mapping.