# Pre9 decoded extent cache final manual validation

Date: 2026-08-13

## Scope

This run validated the mount-scoped decoded LZMA extent cache at enclosing
repository commit `cdcf276d12169a672d2de42996532a470ac061d9`.

Controlled identities:

- `repo-pre-9` tree: `9d7eaf63a1c5d07320af3ef39930fc0a3530dd11`
- `repo-pre-9/src` tree: `e657e8a63b097b061670f75ca01947a568ef33d5`
- guest-built KLD SHA-256:
  `473a6205f43905972f2417609d43f67ab2cb51ea79bc1716fffa5c1914ff85af`
- LZMA image SHA-256:
  `32107a084b27362a093768b88746c37c2e99a74b9f1301a9d4046988479defe9`
- LZMA source SHA-256:
  `ddda39737f0f6093e828a032ec161511fefbb1fa361bc6cbffdbc91e48e4c461`

The existing fresh QEMU process on host port 10030 was reused. No second VM
was created. The guest used FreeBSD 15.0-RELEASE-p8 under QEMU TCG with 6 GiB
RAM and four virtual CPUs. The KLD was built in the guest with
`make WITH_ZSTDIO=0`.

The VM used the existing base image
`/work/tests-dev/lfs/freebsd-15-dev-src-20260811.bp`. Its previously audited
SHA-256 is
`67f359621f23a1d745f0889370cbb99a096cee3e99a0b2f3bb18fc7a91bf6fef`.
This run relied on that established integrity record and did not repeat the
approximately 16 GiB image hash, so base-image hashing did not block the final
validation.

## Verdict

| Area | Verdict | Result |
| --- | --- | --- |
| Guest build, KLD load and fixture mounts | PASS | Build returned zero, `kldload` returned zero and both LZMA and LZ4 images mounted read-only. |
| LZMA single-read correctness | PASS | 4 KiB, 16 KiB, 64 KiB and 1 MiB single `pread()` calls returned the requested bytes with `errno=0`; every output range matched the source range SHA-256. |
| LZMA full-file correctness | PASS | Cold and warm full SHA-256 runs returned zero and matched the 8 MiB source hash. |
| LZMA liveness and performance | PASS | Cold full SHA completed in 2.16 seconds and warm full SHA in 1.44 seconds, both below the 120-second host hard limit. |
| LZMA concurrency | PASS | Two simultaneous full SHA processes both returned zero and the expected hash; guest real times were 22.52 and 21.97 seconds. |
| Non-LZMA regression | PASS | The 8 MiB LZ4 fixture returned the expected SHA-256 in 9.03 seconds. |
| Cleanup and guard integrity | PASS | Test QEMU PID 812999 exited, port 10030 closed, its overlay was deleted, and guard PID 26318/port 9222 remained alive and reachable. |

Overall verdict: **PASS for the required final manual smoke scope**.

## Single `pread()` evidence

Each probe program performs one target-file `pread()`. Truss confirmed one
target call at offset zero for every requested length. Dynamic-loader reads are
not counted.

| Length | Returned | Probe command wall time | Output/source range hash | Verdict |
| ---: | ---: | ---: | --- | --- |
| 4 KiB | 4 KiB | 2.696 s | `1c3c59331a4849514667bbc51c078327577b98f75a62996bbc2fe310b014dd79` | PASS |
| 16 KiB | 16 KiB | 2.140 s | `2433ce7c2ea151f487a319447ce4fe14e1a2c2af9f0e5113fe47fc74b6138eee` | PASS |
| 64 KiB | 64 KiB | 1.369 s | `2bb87afd3b9fab420cbe55b782d69a7342150e8816a35efacf22d2ab3012815d` | PASS |
| 1 MiB | 1 MiB | 3.838 s | `52e806509e5dfeb523904f167fca765d001ea749351ecf51738e61a5352a1ba3` | PASS |

These wall times include SSH and truss overhead and are not pure kernel read
times.

## Full-file SHA evidence

The 8 MiB LZMA source hash is:

`ddda39737f0f6093e828a032ec161511fefbb1fa361bc6cbffdbc91e48e4c461`

| Run | Exit | Guest real time | Captured hash | Verdict |
| --- | ---: | ---: | --- | --- |
| Cold, fresh mount | 0 | 2.16 s | expected hash | PASS |
| Warm, same mount | 0 | 1.44 s | expected hash | PASS |
| Concurrent process 1 | 0 | 22.52 s | expected hash | PASS |
| Concurrent process 2 | 0 | 21.97 s | expected hash | PASS |

The concurrency result shows substantial contention compared with a single
reader, but it completed correctly and stayed well inside the 120-second hard
limit. This run does not claim concurrency performance is optimized.

## Baseline comparison

The preceding controlled Pre7/Pre8/Pre9 run sampled each full SHA after about
eight seconds. Each process was still inside the LZMA decompression path and
had advanced only about 1.0-1.25 MiB; no final hash was captured. That report
therefore classified full-read liveness as failed and correctness as blocked.

With the mount-scoped decoded extent cache, the same 8 MiB fixture completed
with the correct hash in 2.16 seconds cold and 1.44 seconds warm. This closes
the previous full-file correctness block for this fixture and demonstrates a
material liveness improvement. It does not establish a precise speedup ratio,
because the baseline process was terminated at the observation point rather
than allowed to finish.

## Non-LZMA result

The LZ4 compact-64k image contained `compressed.bin` with expected SHA-256:

`3ff012b76087c4da65ce0b69813a76f47ea367e95782edf8b8cd6cd3ec4d1880`

The mounted file produced the same hash, returned zero and completed in 9.03
seconds of guest real time.

## Kernel and cleanup observations

No EROFS panic, assertion, mount error or decompression error was found in the
captured dmesg tail. The image emitted pre-existing root-filesystem directory
warnings during boot; they occurred before the test KLD was loaded and are not
attributed to EROFS.

All test-specific mounts and md providers were explicitly detached before VM
shutdown. A final generic cleanup command contained an awk quoting error, but
it ran only after the explicit LZMA and LZ4 unmount/md detach operations had
already returned zero. Host-side cleanup independently confirmed:

- PID 812999 absent;
- port 10030 closed;
- test overlay absent;
- guard PID 26318 alive;
- guard port 9222 open.

## Uncovered cases

This is a targeted final smoke validation, not a full feature suite. It did not
exercise partial-reference LZMA, metadata tailpacking, fragments, multi-device
images, forced unmount under active I/O, repeated mount/unmount under memory
pressure, or deliberate allocation failure. Those remain separate regression
and stress-test work.

Concise machine-readable evidence is stored in
`docs/pre9-manual-evidence/pre9-cache-final-result.json`. Target syscall lines
are stored in `docs/pre9-manual-evidence/pre9-cache-final-probes.txt`.