nordisk/gunnar

gunnar — details

Reference for gunnar 1.5.0. Every number carries the date it was measured and the box it was measured on. A dash means no measurement exists.

1. Storage

One trait, git-storage-trait::GitOps, with two implementations picked at runtime by GUNNAR_ENGINE (crates/gunnar-server/src/storage.rs). Same server, same wire, same process, different store.

Storing pack entries inflated per oid measured 3.4× larger than the input over 60 000 small objects and removes the pack-copy path.

gix is used as a codec by both engines: pack headers, varints, delta ops, object grammar. It owns no handle and decides no byte placement.

What one repository costs on disk — XFS, 2026-10-06

crates/gunnar-server/tests/repo_overhead.rs lists every file of a repository with its apparent and its allocated size, and holds a small repository under 100 KiB.

The whole fixed cost was the one redb file per repository: redb 2 allocates 540 KB creating a database and 1.6 MB once it has been closed. The other six files take one 4 KiB block each. The tail runs on redb 4 through znippy-plugin-git 0.1.8 (the change, published); an older store's redb 2 tail is copied into redb 4 the first time the store opens (tests/old_layout_store.rs opens a data directory the old build wrote). The transaction log is ~500 B allocated per entry with no preallocation; the load test's "~180 KiB of disk per txlog entry" was this tail divided by the ~7.7 entries one repository's create and push write.

2. Write path

A crash between the two fsyncs leaves object bytes that no row references. It does not leave a row referencing absent bytes.

Writer bench — the desktop, 2026-08-07

Real packfiles, one distinct pack per iteration, /dev/md1 raid0 NVMe, real fsyncs, load average recorded per cell. The 8 KiB rung, index included.

Cost of durability by pack size: 123× at 200 B, 34× at 8 KiB, 4.3× at 512 KiB, 2.4× at 32 MiB.

Method note: the five arms do not produce the same artifact. git and the gix library resolve every object and emit a per-object .idx before returning; gunnar's arms store the bytes verbatim and hand an extent to the indexer, and its index is six columns per pack. io_uring is 1 io_uring_enter against 4 syscalls, measured, and buys 4–7% at mid size while losing at both ends: about 95% of a durable append is the device answering the fsync.

Read side, same day: server CPU on a clone 0.0840 s → 0.0637 s (−24.2%); the client is 9.43× stock git after a TCP_NODELAY fix.

3. Engine matrix — znippy against gix

The desktop, 2026-09-01. 256 / 2048 / 16384 commits, 5 repetitions plus warm-up, both engines in one binary on the same corpus. Load-1 mean 13.4 during the run: per-cell spreads are tight and non-overlapping, so the ratios hold; the absolute times are provisional.

End to end, 16384 commits

Per operation

gix has no reachability bitmap until gc runs, which is the mechanism behind the reachable row.

Optimizations this suite produced

Both landed in znippy (plugins/native/znippy-plugin-git/), each proven byte-identical to the previous path and across a fold-changing push.

A gix read figure taken before 2026-08-11 16:12 UTC is void: edda 05be139 writes a real EWAH .bitmap at gc and reads it in select, and de58ccc routes GitOps::reachable through the same seam. Select went 19.070 → 0.110 CPU-s.

4. Forge matrix

The desktop, 32 cores, 2026-08-13, 3 interleaved rounds, load average 4.39. Same client (git 2.53.0), 8.00 CPUs and 8192 MB per engine read back out of each container's own cgroup. Byte counts taken by a counting relay in front of every engine, never from an engine's own accounting. gunnar is the znippy engine; the comparison column is the better of gitea and Forgejo.

Peak anonymous RSS on a clone is flat across a 108× range of work while both Go forges scale with the repository size. The level is not stable: it was measured three times in two days with a different result each time, and the ramped arm holds a fraction of it for the identical corpus. What is established is that gunnar spends an order of magnitude more resident memory than gitea or Forgejo on every single-client arm. The cause is not established.

Population, the desktop 2026-08-12

Open-loop arm gunnar.population_day, the desktop 2026-08-12: 100 000 users at full identity weight, 50 arrivals/s held 300 s, every operation a fresh process paying a real TLS handshake against --http-tls-self. 49.56/s achieved, 14 893 of 15 000 completed, 107 shed, 0 failures, on 2.55 of 32 cores.

5. Server features

6. Transports and features

git:// is never built. gunnar terminates no TLS: it refuses to read a credential off a plain connection unless the terminator sends X-Forwarded-Proto: https, or --http-allow-cleartext-credentials is passed. A repository marked Public is readable with no key, via the reserved principal anonymous, answered by the same authorisation table as every other principal.

Secrets at rest are sealed with AES-256-GCM (aws-lc-rs). The key-encrypting key lives in secrets.kek, mode 0600, beside the control store, or comes from GUNNAR_SECRET_KEK and is never written. This addresses exfiltration of the data without the disk — a cold-tier archive copied to object storage, a backup, a replica's secrets.arrow. It does not address possession of the disk, root on the running appliance, or its memory.

Concurrency is gatling. rayon is absent from the resolved graph and the absence is asserted by cargo xtask guard.

7. Delivery

Build variants are declared in .nornir/build-variants.toml.

Fast setup — gunnar-quickstart.md. Four numbered lists of commands and nothing else: one appliance; the console beside it; a twin and the two failover flips; the four build lines. Every command in it was run against appliances booted in KVM on the day it was written.

8. Repository tasks

9. Licensing

Source code is AGPL-3.0-only. Original documentation is CC-BY-4.0. The gunnar name and the badger are trademarks owned jointly by Vetra Automation AB and Ignalina ApS and are not licensed. The code is owned jointly by the two companies in equal shares (50/50), and they together offer it under separate commercial terms (contact gunnar@gunnar.rs). Authoritative text and the third-party inventory: LICENSE, NOTICE, THIRD_PARTY_LICENSES.md, TRADEMARKS.md, COMMERCIAL-LICENSING.md.

10. Building against sibling checkouts

A fresh clone builds on its own:

git clone ssh://git.gunnar.rs:2222/nordisk/gunnar
cd gunnar
cargo build --release -p gunnar-cli

Nothing has to sit beside it. Every crate this workspace does not own comes from crates.io, including the fourteen that were path dependencies into ../edda, ../znippy and ../monetize until 2026-09-09:

The one path dependency left is vendor/gix-features, which is inside this repository — see the [patch.crates-io] table in Cargo.toml for why it is vendored and when it goes.

Working on gunnar and a sibling at the same time

To build gunnar against a local checkout of one of those crates, point cargo at it through your own cargo configuration — never through this repository's Cargo.toml:

# ~/.cargo/config.toml   (or $CARGO_HOME/config.toml)
[patch.crates-io]
gunnar-pack       = { path = "/home/you/git/edda/crates/gunnar-pack" }
git-storage-trait = { path = "/home/you/git/znippy/git-storage-trait" }
monetize-embed    = { path = "/home/you/git/monetize/crates/monetize-embed" }

Three things about that placement, each of which has cost someone a day:

• Not in this repository's Cargo.toml. A [patch.crates-io] entry pointing outside the repository puts the sibling checkout back as a hard requirement for everyone who clones, which is exactly the property this change bought.
• Not .cargo/config.toml in this repository either — that file is tracked (it carries the xtask alias and the fmt guard), so an entry there is the same thing with extra steps. And cargo reads no .cargo/config.local.toml: the only files it merges are config.toml and the legacy extensionless config, walking up from the current directory and then $CARGO_HOME. A "local" file next to the tracked one is simply ignored, silently.
• Absolute paths. ~/.cargo/config.toml is read from wherever you run cargo, so a relative path resolves against your shell's directory, not the repository.

A patch is a candidate, not an override: the resolver still takes the greatest compatible version, so a local checkout whose version is behind the registry loses to the registry copy and cargo says patch ... was not used in the crate graph. Bump the local version, or you will debug the wrong source.

To go back, delete the entries. cargo xtask guard and cargo xtask cve both read the resolved graph, so run them with the patches OFF before believing them.