FUSE lookup latency under entry caching

The point of this run was not "is caching faster" — of course it is — but whether atlas-fs's conservative caching from ADR-003 is conservative to the point of being useless. If the TTL is so short that nothing is ever warm, the safety is free only because the cache is.

Method#

Both VMs boot from named snapshots so the kernel starts cold. atlas-fs is mounted read-only; the same five-deep path is resolved 10,000 times per condition. The only variable is whether entry caching is enabled.

  condition A                 condition B
  caching OFF                 caching ON (TTL 1s)
      │                            │
  every lookup ──► upcall      first lookup ──► upcall
                               repeat  ──► served from dcache

Latency is the median per-component resolve time, measured in the guest with a bpftrace probe so the harness itself stays out of the number.

Results#

Discussion#

The short TTL is enough: within a single interactive session the same directories are hit far more than once per second, so the cache stays warm where it matters and expires before staleness becomes a correctness question. This is the behaviour the dentry cache notes predicted, now with numbers from real hardware rather than a hand-wave.