Attribute the ~229 ms per-chunk cost of ordinary files — open-work task 6, and the gate rule R1 holds shut

[TBarregren]

The question, and why it is the one the queue turns on

Ordinary small files cost roughly 229 ms per chunk on the measured production host, unchanged by anything done in 2026-08. Times ~48,500 files that is about three hours — after the large-file catastrophe was solved, this is the entire run. Halving it is worth more than everything measured so far, and nothing has attributed it.

This is task 6 of ~/Projects/kntnt-transfer-engine-open-work.md, and it is still open. The 2026-08-18 production measurement bounded the cost and ruled out per-file path resolution and stat calls as the dominant term for large files; it did not attribute the small-file cost, and it produced no limit-pair reading at all.

An earlier estimate attributed roughly 95 ms of the per-chunk cost to the record-split commit. That estimate did not survive measurement: moving time came in at 257 ms per chunk against roughly 210 ms from the prior release on the same host, so save() was a far smaller share than assumed and the unattributed remainder is very nearly the whole cost.

The hypothesis worth testing first

Filesystem latency. A chunk makes fifteen to twenty-five filesystem calls: realpath() twice, three stats, the file's own open-read-close, and the container's suspend()/resume() pair — two opens, an ftruncate and a close on a file growing past a gigabyte, per 44 KB packaged. At a few milliseconds each that is the right order of magnitude on a managed host whose uploads directory is networked or overlay-mounted. It is a hypothesis and it cannot be settled from a laptop, where the same path costs about 0.25 ms.

Attributing it needs timing inside a tick, which this build does not have. So this is instrumentation work first, then a run on a real host — not a pure measurement task.

Read the free signal first: if a stall shows the host limit raise was granted and the chunk still died, the kill came from the web server or the container rather than from PHP, which on a LiteSpeed host points at LSAPI's process limits and makes the filesystem hypothesis much more likely.

If the per-chunk half holds up, the amortisation to try first is sealing several segments under one open container — no container-format change and no api_version bump, since each file keeps its own segment and its own name on the wire. Coarsening segments into multi-file packages stays decided against; reopen only if all three of these hold: this question is measured, the amortisation is done, and the numbers still demand it.

Rule R1 — what this blocks

Nothing in the adaptation family is built until this is answered. That family is host-limit raising, budget halving, the attempt counter, the floor, and any recovery on top of them. It already has three budgets, a counter, a floor and a halving rule, all chosen blind. If the answer is that the kill comes from the web server or the container rather than from PHP, a smaller chunk is the wrong lever entirely and the right move is to remove knobs, not add one — several queued items are expected to be deleted by the answer rather than done.

Any issue proposing adaptation work should say it is blocked by this one.

Why ready-for-human

It needs a real managed host, and the only host with a measured baseline is a live client site that must never be touched unasked.

Blocked by

An operator decision about which host to measure on, and about landing the in-tick instrumentation first.

[TBarregren]

This was generated by AI during triage.

Triage outcome: deliberately deferred, stays ready-for-human

No measurement is being scheduled now. The maintainer's decision, in their words: 3.5 hours for a full clone is acceptable for the time being, so that a stable and working release can go out — and the ~229 ms is worth digging into after that.

So this is not wontfix. It is intended work with no date, and the reason it cannot be ready-for-agent is unchanged and unfixable by grilling: it needs a run on a real managed host. Nothing on a local NVMe reproduces the cost, where the same code path is roughly three orders of magnitude cheaper. The host decision is an operator decision, and the only host with a measured baseline is a live client site that must never be touched unasked.

What was decided about the blocker

The option weighed at triage was a dedicated scratch site at the same provider, on the same PHP version and the same LiteSpeed setup — representative, and without going near the client site. That option stands and is what to reach for when this is picked up. It was not taken now, and only because a release comes first.

What did change

#39 was split out of #30 and is ready-for-agent: per-phase timing inside a packaging tick, gated behind a Config knob and off by default. That is pure code with no host dependency, and #30 said itself that the work is "instrumentation work first, then a run on a real host". Landing it makes the eventual measurement cheap instead of blocked — when someone does get a host, the build can already answer the question.

#39 is sequenced after the release, since it adds a debug surface and the immediate goal is a stable tag carrying #27's 256 KB default.

Rule R1 is untouched

R1 still holds the adaptation family shut — host-limit raising, budget halving, the attempt counter, the floor — until #30 is answered. That was considered and deliberately left alone: the gate exists so that three budgets, a counter, a floor and a halving rule chosen blind do not get a fourth sibling on a guess, and the maintainer intends to answer the question rather than abandon it. Rewriting the gate would only make sense if the measurement were never going to happen.

Any issue proposing adaptation work should still say it is blocked by #30.

[TBarregren]

This was generated by AI during triage.

Stays ready-for-human — but the prerequisite half has landed

Re-triaged 2026-08-22. The state does not change: this still needs a run on a real managed host, and choosing that host remains an operator decision. Nothing about that is fixable by grilling.

What has changed since the 2026-08-20 note: #39 — per-phase timing inside a packaging tick, behind a Config knob, off by default — was closed 2026-08-21. This ticket's own framing was "instrumentation work first, then a run on a real host". The instrumentation half is done. What remains is purely the measurement, so the "Blocked by" line should now read as one item, not two: an operator decision about which host to measure on. The build can already answer the question the moment a host exists.

The option weighed at the last triage still stands as the thing to reach for: a dedicated scratch site at the same provider, same PHP version, same LiteSpeed setup — representative, without going near the client site.

Rule R1 is untouched. The adaptation family stays shut until this is answered.