[Japabu]

Problem

One refused create, append or sync on /log ended the boot's log file for the rest of the boot, and nothing durable said so (logkeeper-ends-the-boots-log-on-one-refused-create-and-nothing-durable-says-so).

Resulting behavior

• A refused volume is asked again. After 1 s, doubling to 64 s, and at the stop's flush whatever the wait. A LOG server restart is the same refusal.
• The file is given what it missed from the replay. The part is reopened, cut to what its last sync made durable (or rebuilt whole where its file is shorter than that), and written the rest of the boot a part's worth a round. What the replay had already let go is a line in the file in its place.
• The stop is bounded and says its shortfall. The stop's flush waits for a volume still opening and catches the file up within STOP_CATCH_UP (half the supervisor's flush bound), syncs what it wrote, and says in the file and on the console how many bytes short the file ends.
• The stop mark is written only over an open part, and a withheld mark says so in one line.
• A volume adopted late takes the boot at once: adopt gives it a part's worth when its opener answers, and each round after gives it another.

Decisions

• One mechanism gives a file the replay: Volume::catch_up / finish over a per-file offset. logkeeper: the console no longer waits for /log to open #1195's catch-up loop, Hub::owed(&mut u64) and serve::Owed are gone; its opener thread stays.
• The full-log guest row is not carried, by the coordinator's ruling. Its cleanup job cannot write /log after Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196. The record closes on store.rs's host cases; the row's last green was run 42071298691 at 701156896, before Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196.
• No manual page changes: docs/ does not describe logkeeper's refusal handling.

Records

• Closed: logkeeper-ends-the-boots-log-….
• New finding: a-log-volume-full-of-logkeepers-own-parts-is-never-written-again. Retention sweeps only at open and at a rotation, and counts files, not bytes. A full volume holding fewer than sixteen of logkeeper's files is never healed; with sixteen or more, the sweep frees only what the retired files held, and the boot is refused once it has written past that.
• the-console-waits-on-logkeepers-file-writes now lists the loop's blocking calls as they are and says what is left: moving the volume to its own thread.
• a-machine-without-an-iommu-refuses-every-claim quotes the line logkeeper now says where /log is absent.
• a-file-held-across-… is narrowed to DATA reopen; std-file-lock-… stays with M4; the storage track records FUA missing end to end.

Checks at 46a355afb (rebased onto main f9b5d7f12)

• logkeeper tests: cargo test in system/logkeeper: exit 0, 27 passed.
• Host CI: cargo run -- --ci host: exit 1, 1 of 110 steps red. The red is the build system: cargo test --lib, in llvm::tests::the_caller_s_environment_reaches_neither_the_build_nor_the_key, which breaks macOS's git wrapper; it is recorded on main as the-llvm-environment-test-breaks-git-on-macos, and this branch changes nothing under build/. The other 109 steps are green, system/logkeeper's among them.
• Guest run 42909646699 (x86-64 QEMU on the guest runner), exit 0, 3 passed:
  • the_log_lands_on_the_boot_stick: 6 files, 2,539,693 bytes. It needs a guest because it reads back a stick a real boot wrote through the late-adopted catch-up and rotation.
  • a_clean_stop_proves_its_image: the loader's proof over the mark of an open part.
  • acpi_mediated_access.
• Negative controls for store.rs from r2 to r5 still apply: store.rs is unchanged since.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/0decab6627f44f94a74b152dcd5e5de07fa7c866/r8-review-r7 (earlier rounds: r1 to r7-rebase on the same branch)

Risks

• No run shows the stop's flush with the opener unanswered. acpi_mediated_access passed, but its guest stops on the probe's own sleep type and its capture shows no logkeeper line from that path. The path stands on inspection, as in review r7.
• adopt's catch-up has no test of its own. Log is not host-testable, and no row asserts when a just-adopted file first holds bytes. the_log_lands_on_the_boot_stick shows the late-adopted file whole.
• Every boot that stops before /log opens stops up to 2.5 s later.

Earlier rounds' responses and evidence are in the comments above.

🤖 Generated with Claude Code

[Japabu]

Review r1 of #1190 (head cd47061b5, own commits on top of #1185's 33291dbf0)

Architecture

The split of responsibilities is right. Nothing in the kernel changes. The file, its retry policy and its recovery stay in logkeeper, which owns /log. Rebuilding a part from logkeeper's own replay (Hub::since) is a small, direct design: the replay already exists, and it is bounded (REPLAY_BYTES = 16 MiB). The ordering holds. write calls to_volume(text) before hub.append(text), and resume does the same. So a part reopened inside to_volume gets the replay up to the round before, and then writes the round once. The ordinary path does not duplicate bytes. The backoff is bounded (1 s doubling to 64 s, with one retry at the stop's flush), and the doubling test and its control show it.

The change is +262/−89. About 170 net production lines are in logkeeper, and two small host tests are added.

The weak point is the bookkeeping that joins file lengths to replay offsets. Volume::from/durable count bytes in the file, and Hub::since takes a replay offset. The PR assumes the two are always equal, and two of the findings below come from that assumption. The cut-and-rewrite step, which is the main claim of this change, has no test.

Findings

BLOCKER 1. system/logkeeper/src/main.rs:607-610 with store.rs:247,300: the "bytes were let go" note shifts the file's offsets away from the replay's. A later reopen then loses bytes without saying so and starts in the middle of a line.
When lost > 0, the note is spliced into owed. reopen counts it in size (size = durable + owed.len()). The next sync copies it into durable, and the next rotate adds it to from, because from grows by size. But the note is never appended to the hub. From then on, durable_end() is W bytes (the note's length) past the matching replay offset. On the next refusal, since(durable_end()) skips W bytes of real log. Replay::next does not snap to a line, so the rewrite starts mid-line and nothing reports the gap. When nothing new arrived, the offset can also be past the replay's end, and the result is an empty rewrite that holds the wrong position. This path is reachable on a flaky stick: a long outage evicts bytes, then a later refusal follows. That is exactly the case this PR exists for.
Fix: keep the file's offset and the boot's offset apart. For example, record the replay offset each sync made durable, rather than deriving it from file sizes. Alternatively, append the note to the hub as well, so both streams carry it. A host test of the offset arithmetic would catch this; see blocker 3.

BLOCKER 2. system/logkeeper/src/store.rs:242-244: reopen trusts durable when it truncates, and set_len makes a file longer as readily as it makes one shorter.
The brief asks that the rewrite be safe when the durable length is unknown and when the server restarts with a different volume state. reopen opens the file with create(true) and calls set_len(self.durable) without checking the file's actual length. Suppose the file is shorter than durable or missing after the restart: the stick was swapped, the file was deleted from the userland-writable /log, or a sync claimed more durability than it delivered. Then set_len pads it with up to 1 MiB of zero bytes, and the replay is appended after them. The real log bytes in that range are replaced by NULs, even though the replay may still hold them, and nothing reports it.
Fix: cut to min(file.metadata()?.len(), self.durable) and refill from that offset. since then reports whatever the replay no longer holds. The remaining hazard is a foreign volume that carries a file at the same path, such as unknown-NN on another stick. Reopening by path cannot detect it, and reopen would rewrite that other boot's file beyond durable. That waits on volume identity, as the ruling says, but neither record names it. Add one sentence about it to logkeeper-ends-… or a-file-held-across-….

BLOCKER 3. system/logkeeper/src/store.rs (reopen, rotate, durable_end): the claim "cut to what was durable and refilled, nothing lost or duplicated" has no test.
a_lost_file_is_given_the_boot_from_where_it_was_durable tests Hub::since and nothing else. The bookkeeping of from/size/durable across write, failed sync, rotate, a refused next-part create and reopen is never exercised, and blocker 1 sits exactly there. The cheapest sufficient check is a host test. Either make that bookkeeping a small pure type, or make Volume generic over its directory or file, then drive it through these steps: refusal, eviction with the note, a second refusal, a refused rotate. In each case assert that the file equals the replay plus the notes.

BLOCKER 4. system/logkeeper/src/store.rs:242-247: one reopen can write the whole replay into a single part, up to 16 MiB, ignoring MAX_LOG_BYTES.
owed can be as large as REPLAY_BYTES (16 × MAX_LOG_BYTES), and reopen writes all of it into the current part. That breaks contracts stated in this crate:

• MAX_LOG_BYTES is documented as "how large one file may get", and as the bound on what console reads off USB before it paints.
• Retention allows 16 files at 1 MiB within a volume of about 35 MB. A few 16 MiB parts exceed it, and the volume then refuses for good.
• The module header says a part-sized burst of writes "starves a tone playing beside it", and this is a burst sixteen times that size.
• At the stop's flush, the write sits inside the supervisor's bounded wait.

Fix: feed owed through the same part-sized write-and-rotate path, so the rewrite obeys every bound an ordinary write does.

BLOCKER 5. system/logkeeper/src/policy.rs:13-16: the comment's rationale is false.
It says "a stick that recovers within a second or two loses none of the boot's file". How much is lost depends on whether the replay (16 MiB) still holds the bytes, not on the retry wait. A stick that recovers after minutes also loses nothing. Delete the rationale, or state the actual tradeoff: how often a dead stick is asked again, against how soon a live one is used again. It is short and cheap to fix.

SUGGESTION. issues/storage-is-layers-and-a-role-is-a-filesystem.md:139: "Upstream writes the entry as one preflushed Force Unit Access write" puts a fact taken from another implementation's code into the repository. Root keeps that provenance in evidence. State the device fact with its specification instead: FUA makes a write durable without a trailing Flush (NVMe Write FUA, SBC WRITE(10) FUA). The flush-count and the FUA-plumbing claims check out against write_entries (lib/bcachefs/src/engine/mount/mod.rs:1448), which flushes, writes the entry and flushes, with one more round for an entry naming itself.

SUGGESTION. The same paragraph about reopening appears four times: the main.rs header, the Volume doc, Log::lost, and the issue. Keep the Volume doc. reopened(now_or_never: bool) reads as a riddle; ignore_wait or at_stop would say what it does.

Records

• std-file-lock-…: accurate.
• a-file-held-across-…: accurate. The volume id is the server's pid (system/fileserver/src/main.rs:262), and the Stale/Gone claims match toyos::fs. It should name the foreign-volume hazard from blocker 2.
• logkeeper-ends-…: accurate about what was built and about the missing staged break. It stays open honestly, and the choice among (a), (b) and (c) is correctly left to the coordinator. Its sentence "cut to what its last sync made durable" will need to match the fix for blocker 2.
• The FUA finding: accurate, apart from the sourcing in the suggestion above.

Evidence

• f-logkeeper-r3.log: 24 passed on ae16175b4's content. cd47061b5 touches only issues/, so that result carries over to the head.
• Both controls are real mutations, and each turns its test red. They cover the doubling and since's count only, not the rewrite.
• The pre-rebase build-lock red is outside the diff and was green at the head; I accept it as a sighting.
• Guest run 42023375706 was still in progress at review time. It is only a regression check of the ordinary path, which the PR states correctly.
• No run shows a boot that actually retries. The PR says so and keeps the record open.

SEND BACK

[Japabu]

r2 at 8523f4394: response to review r1

All five blockers are fixed in 9e04cbafc.

1. The file's bytes (size, durable) and the replay's offsets (from, through, durable_through) are separate fields. A gap note moves only the file's bytes, and a gap resumes at the replay's own line start.
2. reopen reads the part's length. A part shorter than its last sync is rebuilt whole from its start in the replay and says so. It is never padded. The record names the swapped-stick hazard.
3. a_refused_file_is_given_back_the_boot_the_replay_holds drives a real Volume in a scratch directory through four cases: an unsynced write with torn bytes after it, a refusal long enough for the replay to evict, a refused continuation, and a part cut behind its back. After each, it asserts that the parts are the boot with one note at the gap, and that no part exceeds its bound.
   • Reintroducing blocker 1 turns it red "across the gap".
   • Blocker 2 turns it red "after the part was cut".
   • Ignoring the part's room turns it red on the part's size.
4. Volume::catch_up feeds Hub::owed through part-sized writes and continuations, at most MAX_LOG_BYTES a round. Each part is synced as it fills, and the round's text waits in the replay until the file has caught up.
5. The comment is rewritten.

Both suggestions are taken.

Same round, 8523f4394: the coordinator's option (d), a_refused_log_is_written_whole_once_the_volume_takes_it. The harness fills the stick's log volume. A job removes the filler once logkeeper has been refused, and the stick is read back as a whole boot that carries the refusal and the recovery. The record's exit is amended to this row.

Checks:

• --ci host exit 0.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/5bbdf36084ea913dccbedf8ef68703f5fec57bf0/r2
• Guest run 42027419042 is queued.

[Japabu]

Review r2 of #1190 (head f3a8caa18, own commits on top of #1185's 258e9197d)

Architecture

The design is unchanged and still sound. logkeeper owns the file, the retry and the recovery, and the kernel is untouched. The r2 representation is the right fix: Volume now keeps the file's position (size/durable) apart from the replay's (from/through/durable_through), and Hub::owed → Owed puts the replay's answer behind one small type. catch_up uses the same part-sized write-and-rotate path as an ordinary round. Adding dir to Volume is a genuine boundary for the host test, not test-only machinery.

Size: about +240 net production lines in logkeeper, about +150 lines of host tests, and +100 lines of harness, comprising the row, fill_log_volume and log_unfill.

r1 blockers

1. Resolved. The note goes through put (file bytes only), and Gap sets through = at. rotate takes from from through. The control in f3-lk-controls.log (through = at + note.len()) turns the test red "across the gap".
2. Resolved. reopen checks metadata().len() < durable and rebuilds from from. It never pads. The control turns it red "after the part was cut". Both records now name the hazard of a same-named file on a different stick.
3. Resolved. a_refused_file_is_given_back_the_boot_the_replay_holds drives a real Volume through each step r1 asked for. I checked the three controls in the evidence; each one is a real mutation that the test catches.
4. Resolved for the ordinary path: room = min(rotate_at - size, budget - written). For the stop, see blocker A below.
5. Resolved. The comment in policy.rs now states the actual tradeoff.

The FUA paragraph in the storage track now cites the NVMe and SBC specifications. The duplicated paragraphs are gone.

Findings

BLOCKER A. system/logkeeper/src/main.rs:718-731 with store.rs:313-350: the stop's flush catches up at most 1 MiB, leaves that MiB unsynced, says nothing, and tells the supervisor the log is whole.
flushed calls caught_up(true), and from there catch_up(..., MAX_LOG_BYTES, ...).

• When the file owes more than one part (the replay holds up to 16 MiB), catch_up writes up to 1 MiB and returns Ok(false) once the budget runs out. It syncs only at a rotation or at Owed::Nothing.
• flushed skips both sync() and answered() when caught_up returns false. It then signals FLUSHED anyway, and stopping stops every later to_volume.
• Result: the bytes this catch-up just wrote are never made durable, the rest of the owed boot never reaches the file, and no record says so.

The same silent outcome follows when the stop's catch-up rotates and the next part's create is refused (Ok(false), part not open). Only the Err arm is loud.

The stop is also the backstop for an idle machine. caught_up runs only from to_volume, which runs only on a round that read lines. A due retry therefore waits for the next line or for the stop, and the stop is exactly where the budget truncates.

The case is reachable. The record's own scenario is a long refusal on a busy boot, and the_log_lands_on_the_boot_stick wrote 2.5 MB in this run.

Fix: at the stop, always sync what was written. Then either keep catching up, if the supervisor's bound allows the replay's 16 MiB, or say in the file and on the console how many bytes of the boot the file lacks. Add a host test: a Volume refused while more than MAX_LOG_BYTES arrives, then a stop. Assert either that the file is whole, or that it is synced and carries the shortfall note.

BLOCKER B. tests/toyos.rs:3377 and build/image.rs:403-435: the new row is red at the head (guest run 42030108549), because its fixture does not refuse logkeeper's first write.
The run checked out dataloss-followup at f3a8caa18. nvme_disk_boots and the_log_lands_on_the_boot_stick passed. The new row failed with STALLED: waiting for logkeeper to find the full volume refusing it. In the guest's output, logkeeper printed this boot's kernel log is /log/2026-11-05-130008.log at 2.233 s, and then only clock lines followed. No refusal came.

Probable cause, inferred from the code and not measured: FULL_LOG_KEPT sizes loader.log at 256 KiB, and the loader deletes and recreates that file at every boot (loader/src/loaderlog.rs:148-161). The deletion frees roughly 256 KiB minus the loader's own output, and logkeeper's early boot log fits in that space. The comment on fill_log_volume says the kept files only give a writer "its own room back", and that is false for a writer that deletes and recreates.

The fixture needs a fill that the loader's rewrite cannot undo. For example, size the kept files to what the loader actually writes, or fill after the loader has run. Then the row needs a green run on the guest runner. Until that happens, the record's exit (logkeeper-ends-…: "green on the guest runner") is unmet. The PR's "Guest: … queued" line is stale; correcting it is the orchestrator's job.

BLOCKER C. tests/toyos.rs:3406-3422: once green, the row still cannot show that no bytes were lost or duplicated, but the PR and the record present it as showing the whole boot.
bootlog::verdict (build/bootlog.rs:548) checks only three things: a Boot: complete record exists, no job ran past its bound, and the supervisor's stop line exists. The following would all pass it:

• a file that repeats the replay after an untruncated partial append;
• a file that is missing everything before the refusal;
• a file with a gap note in the middle.

The row's first line is printed, not asserted. In this fixture the first write is refused on an empty file, so blocker 2's cut never even runs. The host test is the real oracle for the bookkeeping, and that is fine. But the row is cited as the exit's proof of "whole".

Cheapest sufficient check, using data the row already has: the console is the independent source. Assert that the stick's kernel records, the non-program lines, equal in order the kernel records on the serial console from the first one to the stop. Also assert that the file has no "were let go" note, and that it begins with the boot's first kernel record. Otherwise, narrow the row's and the record's claim to "the file exists after the refusal and carries the boot record, the stop, the refusal and the recovery".

Records

• logkeeper-ends-…: accurate about what was built, and it stays open. Its exit names a row that is red at the head (B), and that exit should match whatever claim C settles on. The row exercises a refused append, not the refused create from run 69, which is the record's title. Volume::open's refused-create path (file: None at open) has no test, either on the host or in the guest. A one-line host case would cover it, for example a directory placed at the first part's path.
• a-file-held-across-…: accurate. The volume id is the server's pid. The ruling is attributed to the coordinator, not the owner, which is correct.
• std-file-lock-… and the storage-track FUA paragraph: accurate.

Evidence

• f3-lk-c.log: 24 passed on 9e04cbafc's content. f3-lk-controls.log holds four real mutations, each exiting 101. The rebase onto Data-loss burn-down: write-back retry, FAT shrink order and stop recovery, shell redirects, NVMe geometry #1185 r3 leaves logkeeper's diff unchanged, and the host CI at f3a8caa18 is reported green, so I accept that the host result carries over.
• Guest run 42030108549 has completed, and it failed: 2 passed, 1 failed (B). The failure was introduced by this change, not an unrelated red, so it blocks.

SEND BACK

[Japabu]

r3 at a99667bf0: response to review r2

A. Fixed. Volume::finish now does the stop:

• it catches up a part at a time while there is time;
• it syncs what it wrote;
• where the replay holds bytes the file doesn't, it writes a shortfall line into the file, and logkeeper says it on the console as an error.

A next-part create refused during that catch-up ends it the same way. The previous part was already synced by its rotation, and the shortfall goes to the console.

The time is STOP_CATCH_UP, half of the supervisor's bound on the whole flush (toyos_quiesce::FLUSH_MS, 5 s). The other half is for draining the rings, the final sync and the answer. It is a time bound, not a byte count, because how much a stick takes in that time depends on the device. FLUSHED now means "the flush is done", and FLUSH's doc says so.

Host test: a_stop_with_more_owed_than_its_time_syncs_and_says_the_shortfall. A stop with no time leaves a synced file ending in the shortfall; a stop with time leaves a whole file. Three controls each turn it red: no shortfall line, no sync, and no catching up while there is time.

B. Fixed. The cause was what you inferred: the loader deletes and recreates loader.log at every boot, which freed the 256 KiB I had kept for it. fill_log_volume now fills every cluster and keeps nothing. The loader's own writes are refused that boot, which it reports and then boots on (loaderlog's and attempt's refusal paths), and logkeeper's first write is refused. The red run was 42030108549; the row is redispatched as 42036984718, queued. The PR body is corrected.

C. Fixed. The row now checks, against the serial console:

• the stick's first line is the boot's first kernel record;
• each CPU's kernel records on the stick are the console's, in order, with none extra;
• the file has no gap note and no shortfall.

Host case: a_first_part_refused_at_open_is_made_and_given_the_boot. The first part's create is refused, using a directory nothing may be created in. The part is then made at the first catch-up and given the boot from its start.

Checks:

• --ci host at a99667bf0: exit 0, 109 steps.
• logkeeper: 26 passed.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/a9b38564a3aae49b83abc7f84a78c7ba2ba55eea/r3

[Japabu]

The row is green on the guest runner at 6405def8d, run 42040641298: a_refused_log_is_written_whole_once_the_volume_takes_it PASS ("3 file(s), 165 kernel records, the console's in order"), and the_log_lands_on_the_boot_stick PASS.

Two harness-only fixes got it there:

• 0939e4e24: the job is handed to the boot as a test binary. run_test had refused it.
• 6405def8d: the job is typed at the guest. run_test had taken the job's window off the console, so the stick's records looked out of step with a console that was missing lines; a local run showed both sides.

17289151b closes logkeeper-ends-…, since its amended exit is met. The swapped-stick hazard moves to a-file-held-across-….

Evidence: https://github.com/ToyOSOrg/evidence/tree/dfba7eb32340a5793c7da5054a7dc6514e2b571b/r4. Host CI at a99667bf0 still holds: the later commits touch only tests/toyos.rs and issues/, which --ci host does not run, and the harness compiles.

[Japabu]

Review r3 of #1190 at 17289151b (own commits a99667bf0..17289151b on #1185 r4)

Architecture

The design is still right: logkeeper owns the stop's catch-up, and the kernel and supervisor are untouched.

• Volume::finish reuses catch_up in a loop and adds only a sync and a shortfall line. It is a small extension of the existing representation, not a second path.
• A time bound derived from toyos_quiesce::FLUSH_MS is the right unit: the supervisor's bound is time, and the bytes a device takes in that time vary.
• The new toyos-quiesce dependency is an existing workspace crate, used for the constant it owns.

Net change this round:

• About +55 production lines in logkeeper.
• About +50 lines of host tests.
• About +45 net lines of harness. The row's check grows; the fixture loses FULL_LOG_KEPT.

r2 blockers

A. Resolved for the Ok path, but the reported count is wrong on the Err path (blocker 1 below).

• finish loops while more() holds, syncs, and puts the shortfall into the file.
• A refused continuation ends with Ok, with the previous part synced by its rotation and the shortfall stated on the console.
• FLUSH's doc and the panic text now say "the flush is done".
• The three controls in r3/f6-lk-controls.log are real mutations of the three claims (no note, no sync, no loop), and each one exits 101.

B. Resolved.

• fill_log_volume fills every free cluster and asserts free_bytes() == 0 afterwards.
• The loader's refused write is reported by the loader, which then boots on.
• Run 42040641298 (gh run view: head 6405def8d, success) shows both rows PASS.
• 6405def8d..17289151b touches only issues/, so that run stands for the head.

C. Resolved. The row now asserts three things:

• The file's first line is the console's first kernel record.
• Per CPU, the stick's records are an exact prefix of the console's: no mismatch at any position, and no extras.
• No "were let go" note and no shortfall line appear.

This catches the three cases r2 listed: a repeated replay misaligns, a missing head fails begins, and a gap note is matched by text. The begins check also stops the row passing on an empty record set; the run counted 165 records.

Host case and harness changes

• a_first_part_refused_at_open_is_made_and_given_the_boot covers the refused create at open, the record's own case. It checks !is_open() after open, then checks the whole boot after the volume answers.
• Test binary instead of extra_root_files: run_test/run require the binary on ROOT as a test (qemu.rs:1951-1956). This is plumbing and weakens nothing.
• Typed run instead of run_test:
  • The exit-code check is replaced by awaiting log_unfill: /log/FILLER.BIN removed. log_unfill prints that only after remove_file returns Ok, and otherwise exits 1 without it.
  • A failure therefore stalls inside the budget instead of returning at once. That makes the failure slower but no weaker.
  • Keeping the job's window in console is what makes the C comparison sound, so this change strengthens the row.
  • Typing run … is the pattern other rows already use (toyos.rs:3343, 5221, 6141).
• One small evidence gap: r4/guest-42038743967.log is 0 bytes, so the README's account of that intermediate red has no log behind it. It does not bear on the head; it is noted for the record.

Findings

BLOCKER 1. system/logkeeper/src/main.rs:740-746: on the Err arm the console understates the shortfall.

• The Err message prints hub.end() - v.through(). through advances on every successful write, including unsynced rounds (to_volume with sync == false) and rounds whose sync was then refused.
• Log::lost → Volume::lost clears only the file and leaves through ahead of durable_through. Only a successful reopen rolls it back.
• In the record's own scenario, the volume is still refusing at the stop: finish's first catch_up fails in reopen. The message then reports the file as short by end - through.
• finish's own doc says the file is "as its last sync left it". The file that last sync guarantees is short by end - durable_through.
• The same understatement follows a refused put or sync inside finish.
• Consequence: the one durable-loss statement A exists to make reports less loss than may have occurred.
• Fix (cheapest): report the count from the durable point on Err. For example, Volume::lost can roll (size, through) back to (durable, durable_through), which is what reopen does anyway, or finish can return that count with its Err. Then extend a_stop_with_more_owed_than_its_time_syncs_and_says_the_shortfall, or add a sibling, with a stop whose reopen is refused after an unsynced write. The 0o555 directory trick from the new test does this.

BLOCKER 2. system/logkeeper/src/main.rs:600-604: caught_up's at_stop parameter is dead, and its doc is false.

• The only caller left is to_volume's caught_up(false) (:584), now that flushed uses finish.
• The doc still says a refused part "is opened again … or at the stop whatever the wait".
• Fix: drop the parameter and its !at_stop branch, and delete that clause.

Suggestions

• system/logkeeper/src/main.rs:722-723: the flushed doc ("every line is written by now, so the volume is made durable") predates the shortfall path. Either cut it to the contract, or let FLUSH's doc in logstream be the single statement.
• store.rs:472-488: the permission trick refuses nothing when the tests run as root, and then the first assert fails. Host CI is a non-root ubuntu-24.04 runner, so this is not a blocker. A directory created at the first part's path refuses the create for any user.
• Volume::finish takes seven arguments behind allow(clippy::too_many_arguments), and three of them are passed straight through to catch_up. That is acceptable for one caller. If it grows, a small struct holding owed, note and say would serve both functions.

Records

• logkeeper-ends-… is closed by deletion. Its exit ("first log write refused … /log still holds that boot's records … green on the guest runner") is met by run 42040641298. The refused create itself is held by the new host case.
• The swapped-stick hazard moves to a-file-held-across-…, so it is not dropped.
• The commit message attributes the exit amendment to the coordinator, not the owner, which is accurate.

Evidence

• r3/f6-lk-b.log: 26 passed. r3/f6-ci-host.log: --ci host exit 0 at a99667bf0.
• The later commits touch only tests/toyos.rs and issues/, which the host checks do not run, so that result carries.
• Both fixes above are logkeeper-only and need only cargo test in system/logkeeper plus a control. They do not need another guest run: the row never reaches the Err arm.

SEND BACK: blockers 1 and 2.

[Japabu]

r4 at 701156896: response to review r3

1. Fixed. Volume::lost now rolls size and through back to the last sync, as a reopen already did. The stop also calls it on any refusal before counting, so the console's shortfall counts from the last durable position.
   • Host case: a_stop_refused_after_an_unsynced_write_counts_from_the_last_sync. It makes an unsynced write, refuses the volume, then puts a directory where the part was, so the reopen is refused whoever runs it.
   • Control: without the rollback, the test fails.
2. Fixed. The at_stop parameter and its doc are gone.

Root-safe refusal, taken: the first-part test puts a directory at the part's path. ours now lists files only, because a directory is no log part and should not take a part number. Control: listing directories again fails that test.

Checks:

• --ci host: exit 0, 109 steps.
• logkeeper: 27 passed.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/835b39e07505e80434fa51a462c1476bc7b686b2/r5
• The row is rerun at this head, because lost sits on its path: run 42071298691.

[Japabu]

Guest run 42071298691 at 701156896: a_refused_log_is_written_whole_once_the_volume_takes_it PASS ("3 file(s), 165 kernel records, the console's in order").

[Japabu]

Review r4 of #1190 at 701156896 (17289151b..701156896, one commit)

Architecture

Nothing structural changes.

• The rollback sits in Volume::lost. That is where the bookkeeping belongs: reopen already resets (size, through) to the durable point, so lost now records what the file is guaranteed to hold instead of waiting for a reopen.
• Net change: about +10 production lines (logkeeper only), +25 test lines, and −6 lines from removing at_stop.

r3 blockers

1. Resolved.

• Volume::lost rolls (size, through) back to (durable, durable_through) (store.rs:258-261).
• flushed calls v.lost() when finish returns Err (main.rs:740-743), so the console's short counts from the last sync. This covers both ways finish can fail: a refused reopen, and a refused put or sync on an open file that holds unsynced flush rounds.
• I checked the other callers of lost: caught_up's Err arm, Log::lost from answered, and rotate_if_full. After a rotation durable_through == through, so the rollback changes nothing there. On a refusal, publish now reports durable bytes, which is the truer number.
• Where reopen fails after it has reset durable_through to from (a short file, then a refused set_len), lost rolls back to from, which is correct.
• New test a_stop_refused_after_an_unsynced_write_counts_from_the_last_sync (store.rs:531-549). Its control in r5/f10-controls.log removes the rollback line, and the test fails on its shortfall assert (exit 101). The control is real.
• The test reaches only the refused-reopen path. The put/sync-refused path in flushed is held by inspection. See suggestion S1.

2. Resolved. caught_up has no at_stop parameter and no !at_stop branch, and the false clause is gone from its doc (main.rs:600-612).

Findings

BLOCKER 1. system/logkeeper/src/store.rs:74: filtering ours to files only gives a squatting directory the part number, and the boot's log is then refused for good.

• Before this commit, an entry with a part's name was counted whatever its type. Volume::open's part search (:220) skipped it, and the boot wrote to the next part number.
• Now a directory at <stem>-0001 is not in kept, so part 1 is chosen. create fails, and every reopen at each retry fails the same way, for as long as the directory stays. The boot's log reaches the console only.
• undated_stem (:149) has the same hole. A directory named unknown-00-0001 no longer reserves unknown-00, so an undated boot picks that stem and then fails in the same way.
• /log is userland-writable (this module's header names toybox), so any program can now deny logkeeper the boot's file, which it could not do before. That makes the answer to the brief's question yes: a squatting directory now leaves the part number stuck.
• On overwrites: on ToyOS the fileserver always gives the entry's kind, so file_type() does not fail and no real log part drops out of the list to be truncated by create. The filter does widen what create's truncate can reach, though. A symlink with a part's name is no longer skipped, and create follows it. /log is FAT, so that is theoretical today, but it is the wrong direction to move in.
• The change exists only so the r3 suggestion's test staging refuses the create. f10-controls.log says so: the test fails with ours listing directories, "because the part opens at the next number". Root's rule is "No production machinery ships solely to satisfy a test", and here the change also makes the shipped behaviour worse. My r3 suggestion did not account for ours, and that is my error.
• Fix (cheapest): revert the filter. Make the refusal root-safe in the test instead by opening the volume on a log directory that does not yet exist, for example tmp/log. read_dir fails, so ours is empty, part 1 is chosen, and create fails with NotFound for any user. Then fs::create_dir(dir) before the second round. The v.path() == first assert still holds. The new stop test puts its directory at the path reopen opens, which does not consult ours, so it needs no change.

Suggestions

• S1. main.rs:740-743 and store.rs:358-359: finish's doc promises "an Err is … the file as its last sync left it", but the bookkeeping only matches that once the caller calls lost. Calling self.lost() on finish's own Err paths would keep the contract and the code in one place. The new test, or a sibling with a refused sync, would then also hold the open-file path. This is optional, since the current code is correct by inspection.

Evidence

• r5/f10-ci-host.log: --ci host, 109 steps, all green, exit 0.
• r5/f10-lk.log: 27 passed.
• r5/f10-controls.log: two controls, each exit 101 on the intended assert.
• The guest row never reaches these paths (r3 said so). Run 42071298691 is extra; it is not required for this round.
• The fix above touches only store.rs and its test. It needs cargo test in system/logkeeper and no guest run.

SEND BACK: blocker 1.

[Japabu]

r5 at bc1285046: response to review r4

Blocker: fixed. The files-only filter in ours is reverted. An entry under a part's name takes that number whatever it is, and the boot writes the next part.

The first-part test is still root-safe without the filter. It opens the volume on a log directory that doesn't exist yet, so the create is refused with NotFound whoever runs it, and it makes the directory before the second round.

S1: taken. Volume::finish now marks the part lost on its own refusal, so its contract no longer depends on the caller, and the stop no longer calls lost itself. A refused write or sync to an open part can't be staged root-safely on the host, so that path is still held by inspection.

Check: cargo test in system/logkeeper, exit 0, 27 passed. Evidence: https://github.com/ToyOSOrg/evidence/tree/d174fde2b0f51efeec11ba66b767d25ac88935a6/r6

Host clippy on system/logkeeper fails on four lints that predate this branch: two collapsible ifs in inspect.rs, and wrong_self_convention on from_supervisor and to_volume. None is in the changed code, and --ci host's clippy, which uses the adopted lint set, was green at r4.

[Japabu]

Review r5 of #1190 at bc1285046 (701156896..bc1285046, one commit)

Architecture

• Nothing structural changes, and the change makes the code smaller: production code loses about 3 lines and the test loses 1.
• The refusal bookkeeping now lives in one place. Volume::finish's promise that "an Err is … the part lost, the file as its last sync left it" is kept inside finish itself, so the stop in main.rs no longer has to remember to call lost.

r4 blocker

1. Resolved.

• The files-only .filter is gone from ours (store.rs:70-81), and no file_type/is_file check remains anywhere in logkeeper.
• An entry with a part's name now counts as taken whatever kind of entry it is. A squatting directory therefore pushes Volume::open's part search to the next number again, and undated_stem keeps reserving the stem.
• a_first_part_refused_at_open_is_made_and_given_the_boot (store.rs:478-492) now opens the volume on tmp/log, which does not exist yet:
  • read_dir fails, so ours is empty and part 1 is chosen.
  • create fails with NotFound. That holds for any user, root included, so the test is root-safe.
  • create_dir(&log) comes before the second round, and on_disk reads path(dir, STEM, p).
• The test still covers its claim: a first part refused at open is created at a later catch-up and receives the whole boot. Dropping the v.path() == first assert loses nothing, because no squat is staged any more.

S1, as taken

• finish wraps its whole body in one closure and calls inspect_err(|_| self.lost()) on the result (store.rs:370-381). Every ? inside it goes through that one call: the reopen in catch_up, its writes and syncs, the shortfall put, and the final sync. No refusal path can skip the rollback.
• Bookkeeping at the stop. flushed (main.rs:724-747) computes short = hub.end() - v.through() after finish returns. On Err, through is now durable_through, which is exactly what r4's caller-side v.lost() produced. This holds for both ways the stop can be refused:
  • a refused reopen: the file is already None;
  • a refused put or sync on an open part holding unsynced rounds: size and through roll back.
• No harmful double lost. The call in main.rs is removed, and catch_up never calls lost itself.
  • Volume::lost is idempotent: it sets file = None and (size, through) = (durable, durable_through), and neither durable value is changed by lost.
  • The stop tests call v.lost() before finish to stage a refusal. A second call inside finish changes nothing.
  • One case to check: when reopen resets durable_through to from and then fails at set_len, lost rolls back to from, as it did in r4. That is correct.
• No retry is armed when the stop is refused. flushed called v.lost(), not Log::lost, in r4 as well, so this is unchanged. After a resume, caught_up's get_or_insert arms the retry anyway.

Refused write or sync on an open part: no test

• Inspection is enough here. The guarantee comes from the code's shape: one closure, one inspect_err, every fallible step uses ? inside it. A test could catch only a later edit that adds an early return Err outside that closure, and that would be visible in review.
• Volume::lost's own rollback is already guarded by r4's control on a_stop_refused_after_an_unsynced_write_counts_from_the_last_sync.
• Staging an EIO on an open fd on the host would need a fault-injection seam in production code solely for the test, which root forbids.

Findings

None.

Evidence

• I inspected the diff and the touched code in full. As instructed, I ran nothing.
• The implementer reports cargo test in system/logkeeper: exit 0, 27 passed, with the evidence at d174fde2/r6.
• The change touches only store.rs and the stop's call site, so no guest run is needed. r4's --ci host result still stands apart from the compile and test of these two files, which the logkeeper test run covers.
• The four host-clippy lints the implementer reports are in unchanged code and do not appear under --ci host's lint set. I did not verify that claim independently. It does not affect this diff.

LAND

[Japabu]

The evidence branch pr-1190 was rewritten to mask machine identifiers: the T14's vendor, product and BIOS as <vendor> <product>, BIOS <bios>; the guest runner's machine and runner names as <qemu-host> and <runner>; and the runner's home path as <runner>. The body's links are repinned. Links in earlier comments map as follows (old → new):

old	new
d174fde2b	29c1a3d1815ff76dab812969997cb3db20c50b61
835b39e07	ca0b1ad1904e6bc6d377c60a26856e78c134683e
dfba7eb32	7b8b6a8a2469f6b27b43186a7d513b0d19e06e13
a9b38564a	858beb0c3d16f30ff5fd068c4602a46bd8cc76c2
5bbdf3608	51ba7703a1b6ca4feeb180a9b197099c464f5a18

[Japabu]

Review r7 of #1190 at 67601147b (rebased onto 3022fd718, two commits)

I read both commits, the diff against origin/main, all of system/logkeeper/src/main.rs, store.rs and serve.rs at the head, Replay and the stop protocol in lib/logstream, the supervisor's flush/mark, the loader's proof, #1195's review, and the r7-rebase evidence. I ran nothing.

SEND BACK on two small things, both text: comments the reconciliation leaves false, and two issue records it leaves inaccurate. The code itself I found correct.

Architecture

The reconciliation follows the #1195 reviewer's plan and is the simpler of the two shapes.

• One mechanism gives a file the replay: Volume::catch_up / finish. logkeeper: the console no longer waits for /log to open #1195's loop in adopt, Hub::owed(&mut u64), serve::Owed and its test are gone. A late-opened volume is just a Volume whose through is 0.
• The opener thread stays, and still shares only the sync_channel(1) with the loop. The loop remains the replay's only appender.
• store.rs is byte-for-byte r5's apart from Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196's three mark functions and header line (git diff bc1285046 67601147b). In main.rs, caught_up, to_volume, answered, rotate_if_full, lost and the finish call are unchanged since r5. What is new in this round is the thread, adopt/took, the stop's wait on the opener, and mark's is_open condition.
• Size against main: about +285 production lines in logkeeper, +187 of host tests, issues +29/-71.

What I checked in the reconciliation

• Ordering and duplication: none found. A round's text goes to the file only when caught_up says the file stands at hub.end(), and to the replay either way, so a byte reaches the file once, directly or from the replay. That holds for a late-adopted volume, a refused write (lost rolls through back to the last sync), a refused stop (resume writes the held text, then appends it), and a volume adopted inside flushed.
• Stop with the volume still opening. flushed takes the deadline first, then waits on the opener with recv_timeout inside it, so the wait and the catch-up share STOP_CATCH_UP. An answer is given the boot by finish. A timeout says so, leaves opening set, and a refused stop adopts it later. adopt still skips while stopping is set.
• Stop mark. mark writes only when the part is open. I traced every way a volume can have refused by then: never opened, create refused at open, part lost and the stop's reopen or write refused (finish marks it lost itself), a continuation's create refused during the stop, volume dropped at MAX_LOG_PARTS. None is open at MARK, so none is marked. This matches main, where a refusal dropped the volume. Two cases are still marked, both by design as I read STOPPED's doc: a part that ends with the shortfall line because the stop ran out of time, and a file carrying a gap note.
• Earlier findings stay fixed. r1: notes go through put, Gap sets through = at; reopen rebuilds a short part and never pads; the budget bounds a round. r2/r3: finish syncs and says the shortfall; caught_up has no at_stop. r4: ours has no file-type filter. r5: finish marks the part lost on its own Err.
• Main f9b5d7f12. git merge-tree --write-tree origin/main 67601147b exits 0. Main's new commits touch no file this branch does, nor logkeeper, logstream, quiesce or tmpdir.

Findings

BLOCKER 1. Comments on main that this diff makes false and does not touch.

• system/logkeeper/src/main.rs:50 — "The volume is opened on a thread of its own, and nothing waits for it". The stop's flush now waits for it, up to STOP_CATCH_UP (main.rs:775-780). This is the durable rule logkeeper: the console no longer waits for /log to open #1195 moved here from its closed record, so it should state its one exception or lose the clause.
• system/logkeeper/src/main.rs:592-593 ("once it is open, a reader is served only what /log already holds"), main.rs:47-48 ("the replay, which follows the file once it is open") and system/logkeeper/src/serve.rs:5-8 ("after the file has them once it is open") — with this change the replay leads the file whenever the part is refused or still catching up: to_volume returns without writing and hub.append follows. logkeeper: the console no longer waits for /log to open #1195's review made these same sentences a blocker when they were false for a closed file.
• system/logkeeper/src/inspect.rs:49-50 — Degraded is documented as "Every round answered, and slower than a log is worth". The new arm at main.rs:299 publishes it for a part the volume refused.

No test or run is needed for these.

BLOCKER 2. Two issue records this change leaves inaccurate.

• issues/the-console-waits-on-logkeepers-file-writes.md:26-29 — "logkeeper asks a refused volume again and gives the file the boot it missed #1190's per-file offset and bounded stop catch-up ... are its vehicle, so whoever reconciles logkeeper asks a refused volume again and gives the file the boot it missed #1190 with this takes it up." This branch is that reconciliation, and it does not move the file's writes off the loop. Once it lands the record names a holder that does not exist. It should say the offset and the bounded stop catch-up are in the tree and what is left. Its list of blocking calls now also includes catch_up's reopen, and the stop's wait on the opener (bounded).
• issues/a-machine-without-an-iommu-refuses-every-claim.md:42-43 — says logkeeper says no /log on this machine - this boot's kernel log is on the console only when /log is absent. After this change Volume::open answers Some with the part unopened for any refused create, so that machine says ... is asked again - this boot's lines are kept until /log takes them, publishes degraded, and asks every 64 s. Read from the code; the iommu_virtio_platform arm does not assert the line, so it stays green.

Suggestions

• system/logkeeper/src/main.rs:174-177 — the None arm's "no /log on this machine" is now reached only when /log is there and has no free unknown-NN name or part number. Volume::open has already said the true reason; drop the false half.
• system/logkeeper/src/main.rs:816-823 — mark's doc explains only "No volume, no call". The reason for is_open (a refused part's file is not the boot's log) is in the commit message only. A boot whose mark is withheld also says nothing about the mark; one line there would explain the next loader pass's verdict.
• system/logkeeper/src/main.rs:628-638 — adopt no longer writes, and caught_up runs only from a round that read lines. A volume adopted in the iteration after the round that carried its own LOG_OPENED line holds nothing until some later line. The window is small and the stop covers it; calling caught_up from adopt would keep main's behaviour.
• The reason the row cannot be rebuilt (retention sweeps only at open and at a rotation, so a full volume holding logkeeper's own old parts is never healed) is a product limit, recorded only in a commit message. Worth a finding.

Dropping the row and closing the record

Honest, as far as I can verify.

• The stated cause is in the run: log_unfill: /log/FILLER.BIN would not go: the directory is read-only to this process.
• The second reason is true of the code: sweep is called from Volume::open and rotate only, and reopen does not sweep. With 16 or more files the open's sweep frees room before the first create, so nothing is refused; with fewer, nothing ever frees it.
• The harness for the row (build/image.rs, tests/common/qemu.rs, log_unfill.rs, the row itself) is gone from the head, whose tree outside system/, lib/, Cargo.lock and issues/ is main's.
• The record closes on the seven store.rs cases, whose controls from r2 to r4 still apply because store.rs has not changed. The commit message says plainly that the end-to-end run predates Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196 and that the row is not carried. The later run 42071298691 at 701156896 is the row's last green and could be cited instead of 42040641298.
• The slug is cited nowhere in the tree, and the durable rule is in main.rs's header.

Evidence

• Host: ci-host.log ends Host(None): 109 step(s), all green, exit=0, and its system/logkeeper step ran 27 tests. The log does not name its revision; I take 3d7e96592 from the README. git diff 3d7e96592 67601147b only removes the row's four harness files, restoring main's, so the result carries to the head.
• Guest run 42133377735: the log shows the checkout of 3d7e965925805f86e2a1d758e3158e369cc16ba4. Three rows pass. the_log_lands_on_the_boot_stick (6 files, 2,578,602 bytes) exercises the late-adopted catch-up and rotation end to end, and a_clean_stop_proves_its_image the mark over an open part.
• Unplanned evidence in the stalled row: on the full volume the fileserver refuses the part at 3.991, 6.043, 10.096 and 18.151 s, the 2, 4, 8 s doubling. That is the refusal and retry running on the rebased code. Recovery is not shown there.
• Gap, not blocking: no run reaches flushed with the opener unanswered. acpi_press_is_one_sci ends at the probe's TEST_END and never stops the machine. I accept the path by inspection: recv_timeout is used the same way in the supervisor and swap, the wait is inside the supervisor's 5 s bound, and 2.5 s of quiet is far under GUEST_QUIET (15 s). An acpicase row that ends in a stop, such as acpi_mediated_access, would show it if wanted. Every boot that stops before /log opens now stops up to 2.5 s later.

For the orchestrator

• The PR title still says "recovery finishes a half-done FAT rename". Nothing in this diff touches FAT; that part landed with Data-loss burn-down: write-back retry, FAT shrink order and stop recovery, shell redirects, NVMe geometry #1185.
• No manual page changes are needed: docs/ does not describe logkeeper's refusal handling, and the mark's rule is unchanged from main in effect.

SEND BACK: blockers 1 and 2.

[Japabu]

Response to review r7 (head 46a355afb, rebased onto main f9b5d7f12)

Blocker 1, comments. All five sites now say what the code does:

• main.rs header: the replay follows the file while the file has all of it and leads it while the part is refused or catching up; the volume's thread is waited for only by the stop's flush, within STOP_CATCH_UP.
• main.rs write and serve.rs header: the same rule at the append.
• inspect.rs: Degraded is a slow volume or a refused part.

Blocker 2, records.

• the-console-waits-on-logkeepers-file-writes: the offset and the stop's catch-up are in the tree; what is left is moving the volume to its own thread. The blocking calls are listed as they are now, including catch_up's reopen and the stop's bounded wait on the opener.
• a-machine-without-an-iommu-refuses-every-claim: quotes the line logkeeper now says, degraded, and the retry.

Suggestions, all taken.

• The None arm no longer says there is no /log.
• mark's doc gives the reason for is_open, and a withheld mark says so in one line.
• adopt calls caught_up (code change, wants a focused look). To keep the stop's writes inside its deadline, flushed no longer goes through adopt: recv_timeout takes an answer already queued, and finish alone writes there. An opener that ended without answering is the same panic in both places, where the stop used to read it as a timeout.
• New finding: a-log-volume-full-of-logkeepers-own-parts-is-never-written-again.
• The issues commit cites run 42071298691 as the row's last green.

Checks at 46a355afb.

• logkeeper: 27 passed, exit 0.
• Host CI: exit 1, 1 of 110 red. The red is the build system's LLVM environment test breaking macOS's git, recorded on main as the-llvm-environment-test-breaks-git-on-macos; this branch changes nothing under build/. The other 109 are green.
• Guest run 42909646699: the_log_lands_on_the_boot_stick (6 files, 2,539,693 bytes), a_clean_stop_proves_its_image and acpi_mediated_access PASS.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/0decab6627f44f94a74b152dcd5e5de07fa7c866/r8-review-r7

Not shown. acpi_mediated_access stops on the probe's own sleep type, so no run yet reaches flushed with the opener unanswered. adopt's catch-up has no test of its own: Log is not host-testable and no row asserts when a just-adopted file first holds bytes.

[Japabu]

Review r8 of #1190 at 46a355afb (rebased onto f9b5d7f12)

Scope: what changed since 67601147b. git range-diff shows the first commit identical, the second differing only in its message (the run it cites), and one new commit, 46a355afb. I read that commit, all of system/logkeeper/src/main.rs, store.rs, policy.rs and the changed headers at the head, the supervisor's flush/mark/answered, std's bounded-channel recv, the three changed records and the r8-review-r7 evidence. I ran nothing.

SEND BACK on one sentence of the new finding record. The three code changes are correct, both r7 blockers are resolved, and no check needs repeating for the fix.

Architecture

Unchanged from r7 and still the simpler shape: one mechanism (Volume::catch_up / finish over a per-file offset) gives a file the replay, and the loop is the replay's only appender. This round moves no ownership. It adds one caught_up call, removes one adopt call, and splits one Err(_) arm. Net for the round: +110/-40 over six files, of which main.rs is +39/-23 with about half of that comments; no test added or removed.

The three code changes on the stop path

adopt calls caught_up (main.rs:637-640): correct.

• took(None): caught_up returns at volume.as_mut(). Nothing happens.
• An open volume: through is 0, so catch_up writes up to MAX_LOG_BYTES and syncs if it reaches the replay's end. A refusal goes through caught_up's existing arms (lost, the retry, the said line).
• A volume whose create was refused at open: Retry::after(now) is inserted and is not due for 1 s, so nothing is asked. The retry clock now starts at adoption instead of at the next round with a line, which is the better of the two.
• No duplication: the round that follows finds through == hub.end() or catches up further before writing, as at r7.
• adopt still returns first while stopping is set, so the new write cannot happen inside a stop.
• One loop iteration can now write two parts' worth (adopt, then the round). That is the same total work earlier, and the-console-waits-on-logkeepers-file-writes now lists Log::adopt as a caller.

adopt removed from flushed (main.rs:776-789): correct, and the stated reason holds.

• recv_timeout returns a queued answer before it looks at the deadline: std's bounded channel tries start_recv first and checks the deadline only when that fails. So the removed try_recv took nothing recv_timeout does not.
• Had adopt stayed, its new caught_up would write a part and finish would then write its own unconditional first part: two parts with no time check, against r7's one. Removing it keeps r7's bound exactly.

Disconnected panics in flushed (main.rs:787): correct; it cannot fire in a legitimate state.

• The opener's last act is opened.send(volume) on a sync_channel(1). That returns once the answer is buffered, and a buffered message is delivered before a disconnect is reported (empty and disconnected is the only state that yields it). So the thread exiting after sending reads as Ok.
• After the answer, took sets opening = None, so the receiver is never asked again.
• Disconnected therefore means the thread ended without sending: a panic inside Volume::open or the report. That is an invariant violation, and the loop's adopt already panicked on it at every loop top. The only window that used to read it as a timeout was the thread dying during the stop's own wait.
• The stop does not hang on it: the supervisor's answered reads Eof as "logkeeper is gone" and goes on (system/supervisor/src/main.rs:462-465).

Can a volume that opened just before the stop end up empty or unmarked? No, where the volume takes the writes.

• Answered before the loop top that reads FLUSH: adopt takes it and writes a part; the flush's rounds and finish give it the rest.
• Answered between that loop top and flushed: the flush's rounds write nothing (volume is None), recv_timeout takes it at once, and finish runs with the whole STOP_CATCH_UP.
• Answered during the wait, however late: finish calls catch_up once before it asks more(), so the file gets up to a part's worth, then the shortfall line, then a sync. The part is open at MARK, so it is marked.
• Answered after the wait expired: the opener's file stays empty and the stop is unmarked. The console says both (had not opened by the stop, and the new withheld-mark line). This is the bound's intended cost, unchanged from r7; a refused stop adopts it at the next loop top and now writes it there.
• A volume answering with its create refused: finish reopens it whatever the retry wait; if that is refused too the part is lost, not marked, and said.

Time bounds: they hold as at r7. The deadline is taken first; the wait and the catch-up share it; one catch_up of at most MAX_LOG_BYTES plus the sync may run past it, as before. Nothing in this round adds a call outside it.

r7 blockers

Blocker 1 (comments): resolved. I checked each site against the code:

• main.rs:47-55 — the replay follows the file while the file has all of it and leads it otherwise; only the stop's flush waits for the opener. True.
• main.rs:594-596 and serve.rs:4-10 — the same rule at the append. True.
• inspect.rs:49-50 — Degraded covers the refused part. Matches main.rs:301.
• adopt's, flushed's and mark's new comments say what the code does. mark's six lines explain a real invariant.

Blocker 2 (records): resolved.

• issues/the-console-waits-on-logkeepers-file-writes.md — the list of blocking calls matches the loop (to_volume, caught_up from a round and from adopt, rotate_if_full, finish, the mark and its removal). It says the offset and the stop's catch-up are in the tree and names what is left. It no longer names a holder.
• issues/a-machine-without-an-iommu-refuses-every-claim.md:42-47 — the quoted line, degraded and the doubling retry are what the code does for a refused first create, and the record says which part is read from a run and which from the code.

Findings

BLOCKER. issues/a-log-volume-full-of-logkeepers-own-parts-is-never-written-again.md:22-23 — "With MAX_LOG_FILES or more files the open's sweep makes room first and nothing is refused" is not true of the code.

• retire returns existing.len() + 1 - MAX_LOG_FILES files, so with sixteen the open's sweep deletes exactly one. The room it makes is that one file's bytes, not what the boot needs. The record's own second sentence says the count is of files, not bytes.
• On a volume otherwise full, the boot is refused as soon as it has written more than the retired file held. From there it is the defect the record describes: reopen does not sweep, the part never reaches rotate_at, and every retry is refused for the rest of the boot. A rotation retires one more file per new part, with the same shortfall whenever that file was a short one (a boot's last part, or a short boot's only part).
• Consequence: the record puts sixteen or more files outside the defect when they are inside it, so whoever takes it up is told the wrong boundary. The exit as written already covers both cases and needs no change.
• Fix: say that with MAX_LOG_FILES or more files the sweep frees only what the retired files held, and the boot is refused once it has written past that. The PR description's "holding fewer than sixteen" follows the record and wants the same correction.
• This is text read against store.rs; a consistency read settles it and no test or run is owed. (r7's review carried the same sentence in its account of the dropped row; it was wrong there too.)

Suggestions

• The same record, line 22, is one unwrapped line of about 150 columns; wrap it with the fix.

Suggestions from r7

All taken, and right:

• main.rs:176-177 — the None arm no longer claims there is no /log; Volume::open has said the name or part-number reason. No test or record quotes the old line (searched the tree).
• main.rs:825-838 — mark gives the reason for is_open, and a withheld mark is one console line.
• adopt calls caught_up, above.
• The finding exists; see the blocker for its one false sentence. Frontmatter, owner and exit follow issues/README.md, and data-loss fits.
• The issues commit cites run 42071298691.

Evidence

• Guest run 42909646699: the log shows the checkout of 46a355afbfc7b33c4d29800eeef34eee0f1ecd84 and 3 passed, 3 total. the_log_lands_on_the_boot_stick reports 6 files, 2,539,693 bytes. Every boot adopts its volume late, so adopt's new catch-up ran in all three rows, and this row reads the resulting file back whole.
• Host: ci-host.log ends 1 of 110 step(s) red, exit=1. The red is llvm::tests::the_caller_s_environment_reaches_neither_the_build_nor_the_key, failing in macOS's git wrapper on SDKROOT=/no/such.sdk. That is issues/the-llvm-environment-test-breaks-git-on-macos.md on main word for word, and git diff f9b5d7f12 46a355afb -- build/ is empty. I accept it as independent. The system/logkeeper step ran 27 tests green.
• Gaps, stated by the implementer and not blocking: no run reaches flushed with the opener unanswered, and no row asserts when a just-adopted file first holds bytes. Both stand on inspection above; the first is the same gap r7 accepted.

For the orchestrator

• The PR title is corrected. The description is accurate apart from the record's boundary noted in the blocker.
• No manual change is owed, as at r7.

SEND BACK: one sentence in the new finding record.

[Japabu]

Orchestrator verification of the r8 fix (46a355a..7e9ed63), which is record-only: one issue file, +7/-2. The false sentence about sixteen or more files is replaced with what the code does: the sweep frees only what the retired files held, so the boot is refused once it has written past that. The r8 review (#1190 (comment)) found the code correct, and the checks at 46a355a stand. Landing.