<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/research/experiments/013-parallel-syncs/2026-09-27-store-variants-ext4-linux-aarch64.jsonl, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-09-27T13:11:19Z</updated>
<entry>
<title>Measure what moving saves off the owner would buy (084)</title>
<updated>2026-09-27T13:11:19Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-27T13:11:19Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=87480ce170895f841c40930ce24a7a026646ae14'/>
<id>urn:sha1:87480ce170895f841c40930ce24a7a026646ae14</id>
<content type='text'>
Nothing a thread can give: with writes saturated the device's one line of
syncs is the bottleneck, so zeroing the tail or compacting on another
thread only queues that device work behind the commits, and the owner's
idle gap is shorter than one journal commit. Built without compaction the
store is no faster; without compaction and without tail growth durable
posts gain 1.4% and the p99 drops 24% (17.4 to 13.3 ms). New blocks are the
tail latency, so the way to it is a store that rewrites its space in place,
a ring cleaned forward instead of compacted into new files.

</content>
</entry>
</feed>
