-
v0.0.8
StableGates / frontend (push) Successful in 1m34sGates / test (push) Successful in 1m53sGates / test-aarch64 (push) Successful in 6m34sGates / package (push) Successful in 43sGates / test-aarch64 (push) Successful in 7m23sGates / package (push) Successful in 4m11sGates / container (push) Successful in 18sCI / gates (push) Successful in 27m37sRelease / guard (push) Successful in 18sGates / frontend (push) Successful in 1m9sGates / test (push) Successful in 1m36sGates / container (push) Successful in 10sRelease / gates (push) Successful in 9m6sRelease / publish (push) Successful in 4m33sreleased this
2026-08-21 17:25:32 +00:00 | 40 commits to master since this releaseOne constant, chosen from the 0.0.7 field numbers: the checkpoint cadence was the last first-order write cost on the Pi's SD card.
Changed
- The query log checkpoints its write-ahead log every 32 MiB instead of every 4 MiB. Batching the writer in 0.0.7 took the deployed Pi from about 0.5 to 0.281 GiB of writes a day, and about 130 MiB of what is left is checkpoint writeback: SQLite's 1000-page default trips roughly every 40 minutes and rewrites the same hot index and interior pages into
querylog.dbeach time. Every read-write connection toquerylog.dbnow setswal_autocheckpointto 8192 pages, which stretches that to roughly five hours and cuts those in-place rewrites about eightfold, for an expected total near 190 MiB a day. The price is durability under power loss or a kernel panic. Atsynchronous = NORMALa commit does not fsync, so the checkpoint is the only guaranteed durability boundary, and it now sits about five hours of query rows and upstream-history minutes back rather than 40 minutes. Kernel writeback normally makes the real loss far smaller than that, but nothing guarantees it. A process crash or a clean stop still loses nothing that was committed, and the database is never left inconsistent: recovery replays the longest valid prefix of the log. Thequerylog.db-walfile is expected to sit near 32 MiB rather than capped there, since a long-running reader can hold a checkpoint off and let it overshoot, and the daily retention pass still truncates it.config.dbis unchanged.
Artifacts
aaf2b72be2fdbeb2052e0f9dbc23c52aa2b6dea538dc720f001c69cbe6569c75 nxdns-0.0.8-x86_64-linux-musl.tar.gz 0670430fad5b07d45e1d4248deba03ac72420cdcbb1b3c7c25d160c3dbb22f65 nxdns-0.0.8-aarch64-linux-musl.tar.gz 687feb04186aba42ff3ce8d0b8921b37e9ec875c080840dde79a49dc7d69cda6 IMAGE-DIGEST.txtgit.mial.net/mokhtar/nxdns:0.0.8@sha256:f5ec2a8cdae6225d8207e98e305a20a1fb8cba7ab007f6b3113a80ee754e25dfCommits since v0.0.7
b6cea3f build: bump version to 0.0.8 9b0b7c1 querylog: checkpoint every 8192 wal pages instead of 1000Downloads
- The query log checkpoints its write-ahead log every 32 MiB instead of every 4 MiB. Batching the writer in 0.0.7 took the deployed Pi from about 0.5 to 0.281 GiB of writes a day, and about 130 MiB of what is left is checkpoint writeback: SQLite's 1000-page default trips roughly every 40 minutes and rewrites the same hot index and interior pages into