[Japabu]

What

Closes three open severity: [data-loss] records whose code no longer exists. Record-only: no source changes.

record	the code it described	gone in
a-64-mib-write-to-the-in-memory-data-volume-runs-its-file-server-out-of-memory	DATA's format on a Ram block device written through the block cache, when no DATA partition was present	4f2efdb (#1152, e11b6a7). In-memory files are now MemoryVolume, whose bytes live only in the kernel's paged objects. Ram is a host test device.
fat-unlink-reallocate-leaks-a-cluster-under-load	the kernel driving the log volume through toyos-fat32 over its block layer (BudgetExpired)	13ed7b4. The test was deleted in 3aad43b.
console-line-atomicity-loses-five-of-a-thousand-lines-on-ci	the kernel's per-holder console lines (ConsoleLine)	a788d31. The test was deleted in 4505f87.

The commit message gives the reasoning for each. What remains of each subject is covered elsewhere:

• toyos-fat32's unlink and allocation are exercised under refusals and stops by lib/fat32/tests/refused_writes.rs.
• Line loss on today's console path is tracked in issues/the-console-loses-what-its-carrier-had-not-delivered.md.

Checks

• git grep for each slug outside issues/: no hits.
• Markdown deletions only, so no build was run.

Fixes for the records that still apply are in a separate PR.

🤖 Generated with Claude Code

[Japabu]

Review r1 of #1183 at f5bba85

Assessment. This PR only deletes records. I checked each closure against the commit it cites, and in every case the mechanism the record describes is gone from origin/main.

• a-64-mib-write-…: 4f2efdb46 removes RAM_BLOCKS and ram(...) from open_volume and replaces them with MemoryVolume. It reached main only through Consolidate storage around native bcachefs and userland filesystems #1152 (e11b6a784), as the record says. memory.rs holds names and metadata only. File bytes live in the role's pager, whose capacity is sized from memory_total(). The server-heap growth the record measured has no remaining path.
• fat-unlink-reallocate-…: 13ed7b4f4 removes toyos_fat32 from kernel/Cargo.toml and deletes kernel/src/block.rs. That removes both the kernel's FAT and its BudgetExpired block layer. 3aad43b13 deleted the test. toyos-fat32's remove and remove_dir are driven through refusals and stops in refused_writes.rs.
• console-line-atomicity-…: ConsoleLine exists at a788d314b^ (kernel/drivers/serial.rs:320) and not at a788d314b. 4505f872d deleted the test. The pointer to the-console-loses-what-its-carrier-had-not-delivered is correct.

git grep finds none of the three slugs at the PR head.

Required

None.

Suggestions

• The 64 MiB record also carried a metal sighting: on the T14, files took 80 s instead of 13 s and seq_write.1048576 ran below 1 MB/s. That was a throughput stall, not the out-of-memory defect, and closing the record drops it. If anyone still cares about it, one line in a performance record would keep it.
• For fat-unlink-reallocate, the record's second hypothesis was a write-order bug inside toyos-fat32. That code still exists. The closure rests on refused_writes.rs covering unlink and allocation separately; no test checks unlink followed by reallocation into the freed chain. This is acceptable for an unreproducible sighting whose environment is gone. I note it only so the reasoning is recorded.

LAND