Files
felhom-controller/REPORT.md
T
admin 844f19f11e
gates / gates (push) Successful in 31s
fill watch: one warning per filesystem (R-1371) — committed, not released
On a box whose guest has one data volume the two built-in fill targets, "/"
(the controller's overlay on the Docker data volume) and /mnt/sys_drive, are one
filesystem. The target list was de-duplicated by path only, so one fill would
send two warnings under two names.

fillTargets now keeps one target per filesystem; the first stays (app area,
system area, drives). The identity is system.FilesystemKey, not st_dev alone:
inside the container "/" is an overlay with its own device number, so an
overlay path takes the device of a Docker-kept file on the data-root
(/etc/hostname, /etc/hosts, /etc/resolv.conf). Measured read-only on demo-hp
9201/9202 and the N100 on 2026-11-10.

Tests: TestR1371_* (3), TestFilesystemKey_* (2). Red seen three times.
No version, no image, no floor: it waits for a release session.

Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-11-10 14:18:36 +01:00

2.4 KiB

REPORT — one fill warning per filesystem (R-1371) — committed, NOT released (2026-11-10, operator brief)

Plain words first. The controller watches how full the disks are. On a box with one data volume it watched that volume twice, under two names. One full disk would have sent two warnings. The controller now watches each filesystem once. This is a commit only. No version, no image, no floor change. No box has it. It waits for the next release.

The full report of the run is in felhom.eu: REPORT-endings-kernels-fixes-2026-11-10.md.

Change fillTargets / fillTargetsBy in controller/cmd/controller/main.go; system.FilesystemKey (new, controller/internal/system/fskey*.go)
Rule One watch target per filesystem. The first stays: app area, then system area, then drives. A path that cannot be identified is kept
The trap Inside the container "/" is an overlay. It has its own device number (139 against 64519 on demo-hp). A plain device compare changes nothing on a box. The key of an overlay path is the device of a file Docker keeps on its data volume (/etc/hostname, /etc/hosts, /etc/resolv.conf)
Measured Read-only, 2026-11-10, demo-hp guests 9201 and 9202 and the N100: felhom.eu documentation/audits/space-list-2026-11-10/evidence/extra/fs-identity.txt
Tests TestR1371_OneFillSendsOneWarning, TestR1371_TargetsByFilesystem, TestR1371_ProductionListUsesTheRealIdentity, TestFilesystemKey_AnOverlayRootIsTheDockerDataRoot, TestFilesystemKey_RealSyscalls
Red seen 3 times: no filesystem check (2 warnings); the production list not wired to the real identity; an overlay keeping its own device number
Gates python3 scripts/controller_gates.py --fast
Not proven On a box. No disk was filled, so two real warnings were never seen; the double count is read from the target list and the measured filesystems
Not fixed here The guest's own root disk (/opt/docker/stacks lies on it) has no fill watcher. It is a design point in felhom.eu 16-storage-physical-identity.md
Side effect A registered drive that lies on the same filesystem as a built-in area is now watched under the area's name
Machines None changed by this commit. The measurement was read-only

Next. A release session builds it. Then read the watch list in the controller's log on a one-volume box: it must name the data volume once.