diff --git a/issues/a-full-data-volume-frees-space-only-at-a-commit.md b/issues/a-full-data-volume-frees-space-only-at-a-commit.md deleted file mode 100644 index 1575fedcec5..00000000000 --- a/issues/a-full-data-volume-frees-space-only-at-a-commit.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -status: open -kind: defect -opened: 2026-10-09 ---- - -# A full DATA volume frees space only at a commit - -The DATA volume's commit is shadow paging (`lib/bcachefs/src/fs.rs`), so a block -the last committed tree reaches is not free until the next commit lands -(`BitmapAllocator`'s `pending`): an unlink or a truncate of a file a sync -already wrote gives its blocks back only at the next sync, and every change -copies the nodes it touches to new blocks first. On a volume its files filled, -a write that follows an unlink is refused `ResourceExhausted` until fileserver's -next sync, at most `WRITEBACK` later. - -`NODE_RESERVE` (16 blocks) is kept from every change but a delete and an -update whose entry grows no longer, which leave the tree no larger, so a -commit gives back whatever they drew. Its limits: the deletes and shrinks -between two commits on a full volume copy at most 16 committed nodes between -them, and a run that touches more is refused until the next sync; and a tree -deeper than 16 levels could not copy one delete's path at all. Nothing reads -DATA's depth: 16 is a bound picked, not one measured against it. - -Measured on a 1024-block `DataVolume` filled with 841 one-page files and -synced (a scratch host test, not committed), before the reserve was kept from -names with no data: a one-page write after an unlink was refused -`ResourceExhausted` and accepted after a sync; then 13 unlinks of every seventh -file were accepted and the 14th refused `ResourceExhausted`. - -## Exit condition - -On a volume its files filled, an unlink followed by a write of the blocks it -freed is accepted with no sync between them, and so is a delete of every file -on it, measured by a host test of `fileserver::data`. diff --git a/issues/a-guest-with-no-virtio-keeps-no-serial-when-its-run-reds.md b/issues/a-guest-with-no-virtio-keeps-no-serial-when-its-run-reds.md deleted file mode 100644 index 061c37e7882..00000000000 --- a/issues/a-guest-with-no-virtio-keeps-no-serial-when-its-run-reds.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -status: open -kind: tooling -opened: 2026-09-27 ---- - -# A guest with no virtio device keeps no serial when its run reds - -`tests/common/lane.rs`'s `keep_serial` copies a red run's `uart-*.log` files to -`target/red-run-serial`. A profile with no virtio device (`qemu_command`'s -`shape.virtio.present()` false: `Profile::Metal`, and every `power.rs` guest -built on `panicked()`) routes its 16550 to QEMU's stdio instead, so its only -record is the reader thread's memory, and the kept lane directory is empty. The -console stream of a virtio guest is not kept either; only its UART is. - -**Evidence:** `syscall_fault_halts` red at `8e525da4`: the run printed -`this red run's serial logs are kept at target/red-run-serial/toyos-tmp-45425-0`, -and that directory's `lane-0` is empty. The check's own error carried no -capture, so what the kernel said was lost. - -**Exit condition:** every guest's console, whichever device carries it, is -written under its lane as it is read, and a red run keeps it; a red -`panic_reboots` run shows a non-empty kept lane. diff --git a/issues/a-red-run-keeps-no-serial-for-a-boot-whose-uart-is-qemus-stdio.md b/issues/a-red-run-keeps-no-serial-for-a-boot-whose-uart-is-qemus-stdio.md index 4ef28b8d680..563cccc159c 100644 --- a/issues/a-red-run-keeps-no-serial-for-a-boot-whose-uart-is-qemus-stdio.md +++ b/issues/a-red-run-keeps-no-serial-for-a-boot-whose-uart-is-qemus-stdio.md @@ -14,6 +14,12 @@ console's port (`toyos_build::vmconsole::UartSocket`). Where the 16550 is QEMU's stdio, the console exists only in the harness's memory, so a red boot of such a profile leaves no file. +A console-port boot's console is not kept either; only its UART is. Its +console is the virtio-serial port on QEMU's stdio, which the harness also +holds only in memory (`tests/common/qemu.rs`'s `read_consoles`), and its +`uart-.log` holds what the loader said and the lines the port cannot +carry. + Guest-rows 42010705757 reddened `acpi_press_is_one_sci` (`Profile::HeadlessNoConsolePort`) with a STALL, and its `serial` artifact held one file: lane-2's `uart-4.log`, a passing console-port boot of diff --git a/issues/a-refused-delete-has-already-thrown-the-file-away.md b/issues/a-refused-delete-has-already-thrown-the-file-away.md deleted file mode 100644 index a9db8045216..00000000000 --- a/issues/a-refused-delete-has-already-thrown-the-file-away.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -status: open -kind: tooling -opened: 2026-09-05 ---- - -# No test stages a delete the device refuses - -A delete that fails on the device has to leave the file as it was: its name, -its blocks, and every holder's view of it. `userland/fsd` asks the volume -first and only then marks the open file gone (`DataVolume::unlink` in -`userland/fsd/src/data.rs`, `FatVolume::unlink` in `userland/fsd/src/fat.rs`), -which is the order that keeps it; the kernel adapter this file was filed -against discarded the cached file, the name and the blocks before it asked. -Nothing stages the refusal, so the order is read off the code and not run. - -**Exit**: a host test in `userland/fsd` whose disk refuses the reads or writes a -delete makes, and finds the name, the bytes and an open holder's reads as they -were before the refused call. diff --git a/issues/no-test-holds-what-a-full-data-volume-takes-with-no-commit-between.md b/issues/no-test-holds-what-a-full-data-volume-takes-with-no-commit-between.md new file mode 100644 index 00000000000..39d8c65badc --- /dev/null +++ b/issues/no-test-holds-what-a-full-data-volume-takes-with-no-commit-between.md @@ -0,0 +1,33 @@ +--- +status: open +kind: tooling +opened: 2026-11-11 +--- + +# No test holds what a full DATA volume takes with no commit between + +A bucket is written again only once its emptying is durable +(`lib/bcachefs/src/engine/mount/allocator.rs`), so on a volume its files +filled, the space an unlink frees is not free at once. `Mount::grant` does +not refuse a change for room while an emptying awaits durability (`settled`). + +The engine's tests of a full volume commit between the two: +`a_full_data_volume_can_release_a_large_orphan_and_use_its_capacity_again` +(`lib/bcachefs/src/engine/tests/data.rs`) and +`a_full_volume_refuses_changes_by_name_and_still_removes_names_and_unmounts_clean` +(`lib/bcachefs/src/engine/tests/buckets.rs`). A scratch copy of the first +without its second commit, at 422915e2c, refused a 1 MiB write before the +unlink (`NoSpace`) and took it after the unlink and release. It is not +committed. + +The second removes 21 names between two commits on a full volume, not every +file, and a removal's grant can still answer `NoSpace("no room left for the +btree nodes a removal may write")` (`Draw::Freeing` in `Mount::grant`). No +test removes every file of a full volume with no commit between. + +## Exit condition + +On a volume its files filled, host tests hold that an unlink and release +followed by a write of what it freed is accepted with no commit between them, +and so is a delete of every file on it. Each is red when the grant refuses +instead of waiting. diff --git a/issues/no-test-stages-a-delete-the-device-refuses.md b/issues/no-test-stages-a-delete-the-device-refuses.md new file mode 100644 index 00000000000..20c7c988f2b --- /dev/null +++ b/issues/no-test-stages-a-delete-the-device-refuses.md @@ -0,0 +1,21 @@ +--- +status: open +kind: tooling +opened: 2026-09-05 +--- + +# No test stages a delete the device refuses + +A delete that fails on the device has to leave the file as it was: its name, +its blocks, and every holder's view of it. The file server asks the volume +first and only then lets the open file go: DATA's `unlink` +(`system/fileserver/src/data.rs`) releases the file's blocks only after the +engine's unlink answered, and FAT's (`system/fileserver/src/fat.rs`) marks the +open file gone only after `remove` did. Nothing stages the refusal, so the +order is read off the code and not run. FAT's +`an_unlink_stopped_anywhere_is_recovered` stops the device for good and judges +the next mount, not a server that goes on answering. + +**Exit**: a host test in `system/fileserver` whose disk refuses the reads or +writes a delete makes, and finds the name, the bytes and an open holder's +reads as they were before the refused call. diff --git a/issues/the-cxx-runtime-is-rebuilt-for-every-sysroot-key.md b/issues/the-cxx-runtime-is-rebuilt-for-every-sysroot-key.md deleted file mode 100644 index 75d35b9c562..00000000000 --- a/issues/the-cxx-runtime-is-rebuilt-for-every-sysroot-key.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -status: open -kind: tooling -opened: 2026-10-01 ---- - -# The C++ runtime is rebuilt for every sysroot key - -`sysroot::build` builds libc++, libc++abi and libunwind for both userland -targets into every new sysroot (`libcxx::build`), so every `toyos-abi` edit -pays for them. Their inputs are the compiler's LLVM, `libcxx::OPTIONS` and the -C sysroot they compile and link against: libc's headers and its staticlib. An -ABI edit moves only the staticlib. Measured on the `wt/toyos-rebuild` branch, -one item added to `sdk/abi/src/clock.rs`: 27 s and 38 s at load 41, 47 s and -54 s at load 68. - -**Exit**: one item added to `sdk/abi/src/clock.rs` after a build, and the -next `cargo run -- --build-only` prints no `Building the C++ runtime`. diff --git a/issues/the-cxx-runtime-is-rebuilt-with-every-sysroot.md b/issues/the-cxx-runtime-is-rebuilt-with-every-sysroot.md index 17c61cfa6e6..92db6f66bf5 100644 --- a/issues/the-cxx-runtime-is-rebuilt-with-every-sysroot.md +++ b/issues/the-cxx-runtime-is-rebuilt-with-every-sysroot.md @@ -9,7 +9,9 @@ opened: 2026-09-30 `build/sysroot.rs` builds each target's libc++, libc++abi and libunwind into the C sysroot after libc, so every change the sysroot key sees, an edit to `sdk/abi/src`, `sdk/toyos/src` or libc's `src/` among them, configures and -builds both targets' runtimes again. +builds both targets' runtimes again. One item added to +`sdk/abi/src/clock.rs`, measured on the `wt/toyos-rebuild` branch, cost 27 s +and 38 s at load 41, and 47 s and 54 s at load 68. The runtime is a function of the LLVM key, libc's `include/` and `build/libcxx.rs` only if no configure probe links: the runtimes' `try_compile` @@ -22,4 +24,6 @@ against today's before it is set. **Exit**: with the probes shown not to need a link, the runtime is a store product of its own, keyed on the LLVM key, libc's `include/` and -`build/libcxx.rs`, and a sysroot build takes it (the store is #629's). +`build/libcxx.rs`, and a sysroot build takes it (the store is #629's): one +item added to `sdk/abi/src/clock.rs` after a build, and the next +`cargo run -- --build-only` prints no `Building the C++ runtime`.