local 9P performance slow #2

New issue

Open

opened 2026-08-25 14:50:11 +09:00 by xyz · 1 comment

xyz commented

2026-08-25 14:50:11 +09:00

{"command":"cd /mnt/endo-work && git status --short | head && echo \"--- branch:\" && git rev-parse --abbrev-ref HEAD && git log --oneline -2"}

timed out after 2 minutes

the repo is large, so maybe this is unavoidable but worth investigating since everything is local

``` {"command":"cd /mnt/endo-work && git status --short | head && echo \"--- branch:\" && git rev-parse --abbrev-ref HEAD && git log --oneline -2"} ``` timed out after 2 minutes the repo is large, so maybe this is unavoidable but worth investigating since everything is local

floot referenced this issue

2026-08-28 17:09:53 +09:00

machine-admin prompt: correct the worked examples and state the exec compartment rules #24

floot commented

2026-08-28 17:10:14 +09:00

Owner

Fresh measurement, 2026-08-28, on a newly attached read-only bind
(endo-state-ro at /mnt/endo-state):

Reading a 4.6 MB file through the bind sustained roughly 3 KB/s.
wc -l on it did not finish inside the 2-minute Bash timeout.
The same file via E(fs).readText([...]) returned in about a second.

So the capability path is on the order of a thousand times faster than the
bind that exists to make capability access convenient.

Evidence from session mt82q1ns-l8nrge that this is not just a benchmark
artifact — these all ran against /mnt/endo-work:

cd /mnt/endo-work && git status --short      -> Exit code 143, timed out after 2m
git merge-base <a> <b>                       -> Exit code 124
git rev-parse --abbrev-ref HEAD              -> ~100s

The agent eventually abandoned in-container git for inspection and routed it
back through a capability (E(endo-work-shell).exec('git', [...])), which is
the opposite of what the bind is for. Editing still worked because writes are
small; anything that walks the tree does not.

Fresh measurement, 2026-08-28, on a newly attached read-only bind (`endo-state-ro` at `/mnt/endo-state`): - Reading a 4.6 MB file through the bind sustained roughly **3 KB/s**. `wc -l` on it did not finish inside the 2-minute Bash timeout. - The same file via `E(fs).readText([...])` returned in about a second. So the capability path is on the order of a thousand times faster than the bind that exists to make capability access convenient. Evidence from session `mt82q1ns-l8nrge` that this is not just a benchmark artifact — these all ran against `/mnt/endo-work`: ``` cd /mnt/endo-work && git status --short -> Exit code 143, timed out after 2m git merge-base <a> <b> -> Exit code 124 git rev-parse --abbrev-ref HEAD -> ~100s ``` The agent eventually abandoned in-container git for inspection and routed it back through a capability (`E(endo-work-shell).exec('git', [...])`), which is the opposite of what the bind is for. Editing still worked because writes are small; anything that walks the tree does not.

floot referenced this issue from a commit

2026-09-08 22:41:41 +09:00

design(cbor-codec): reflect landed framing names @endo/cbor-frame / @endo/syrup-frame

floot referenced this issue from a commit

2026-09-08 22:41:41 +09:00

refactor(exo-npm): summary-fix bundle from the barrister verdict

floot referenced this issue from a commit

2026-09-08 22:41:41 +09:00

fix(ironhorse-vm): refuse suspend below the run's stack base (CI fuzz trophy #2)

floot referenced this issue from a commit

2026-09-08 22:41:41 +09:00

fix(ironhorse,xsnap): apply panel review to the Panic category + FFI guard