advanced.concurrency bounds both the network upload pool and the local hashing pool

[eiserv]

What

advanced.concurrency controls two unrelated resources. In internal/uploader/transfer.go it bounds the network upload pool:

g, ctx := errgroup.WithContext(ctx)
g.SetLimit(cfg.Concurrency)

and in internal/uploader/sync.go the same value is handed to the local hashing pool:

if err := hashPlanFiles(ctx, p.files, cfg.Concurrency, cached); err != nil {

which uses it as g.SetLimit(concurrency) over hashFile calls (internal/uploader/planner.go).

docs/configuration.md documents this honestly ("Also bounds the sync hashing worker pool"), so it is not hidden. It is still the wrong coupling.

Why it matters

The two pools are limited by different things and want different values:

• Uploads are bounded by the server: its per-connection limits, its disk, the link's bandwidth-delay product, and how much parallelism it tolerates before it starts refusing or throttling. The reason a user lowers this value is almost always "my server does not like many parallel writes".
• Hashing is bounded by the runner: CPU cores and local disk throughput. It never touches the server at all.

So the user with the fragile shared-hosting server sets concurrency: 1, which is the correct instruction for the upload pool, and as a side effect makes a sync of a large tree read and SHA-256 every local file strictly one at a time. On a 4-core runner that is roughly a 4x slowdown of a phase that has nothing to do with the reason they set the value. It lands hardest on exactly the sync-with-many-files case that #30 (parallel hashing) was added to fix.

The reverse is true too: a user with a fast server who raises concurrency to 32 to fill a fat pipe now runs 32 concurrent file reads on the runner's disk, which for spinning or throttled storage is worse than 4.

Suggested direction

Decouple the hashing pool from the transfer pool. The lazy version is the right one here: hashing does not need its own config knob, it needs a sensible internal default.

hashPlanFiles(ctx, p.files, runtime.GOMAXPROCS(0), cached)

That is one line, removes the surprise, and needs no new configuration surface (which matches the "most new knobs belong in the simpler category, and preferably nowhere" principle in CLAUDE.md).

If a knob turns out to be genuinely needed later, advanced.hash_concurrency is the natural name, but it should not be added speculatively.

The line in docs/configuration.md that documents the current coupling would be removed in the same change.

[nickolep]

Still current, but the existing benchmark does not show a material problem yet. In the stored 500 x 4 KiB sync redeploy at the default cell, the hash phase was about 47 ms out of 1,168 ms total, roughly 4%. That payload is only 2 MiB, so it cannot answer this issue.

A useful check should isolate local hashing from SFTP:

• prepopulate an unchanged sync target
• keep sync.fast_path off so every local file is read
• use enough data to dominate fixed network cost, for example 32 to 64 files of 32 to 64 MiB
• compare hashing workers 1, 2, 4, 8 and runtime.GOMAXPROCS(0)
• record hash wall time, user CPU, peak RSS and total run time on the fixed runner
• run at least 3 repeats; do not add this large payload to the permanent standard scenario set

A local Go benchmark for hashPlanFiles is likely cheaper and more stable than extending the SFTP matrix, with one real sync run as an integration check. If the result supports decoupling, using an internal CPU-derived cap without adding a user-facing knob is the right KISS implementation.