Skip to content

fix(disks): eliminate DragonFly disklabel fan-out and md phantoms#28

Merged
ncode merged 1 commit into
mainfrom
juliano/optimize-bsd-disks
Jul 1, 2026
Merged

fix(disks): eliminate DragonFly disklabel fan-out and md phantoms#28
ncode merged 1 commit into
mainfrom
juliano/optimize-bsd-disks

Conversation

@ncode

@ncode ncode commented Jul 1, 2026

Copy link
Copy Markdown
Owner

Summary

The DragonFly disks/partitions probe had two independent problems, both confirmed on the nlab DragonFly guest while diagnosing the CI timeout:

  1. Fan-out. dragonFlyDisklabelTargets blindly probed device + s1..s4 (plus the whole disk) for every device in kern.disks. The guest lists 132 devices (da0, vn0..3, md0..md126), so one discovery spawned ~660 disklabel processes, of which exactly one (disklabel da0s1) was productive.
  2. Phantom disks. The 127 empty md memory disks leaked into the disks fact as phantom 9.77 MB disks (diskinfo /dev/md0 returns a positive size).

What changed (DragonFly only)

  • dragonFlyPseudoDisk skips md/cd pseudo-devices (matched by driver class — name with trailing digits stripped) in both the disks list and the partition probe.
  • dragonFlyDisklabelTargets now globs the slice nodes that actually exist (/dev/<dev>s<N>) instead of the fixed s1..s4, and drops the never-productive whole-disk target (the DragonFly label lives on the slice; disklabel da0 returns Operation not supported).
  • currentDragonFlyPartitions takes s.glob. Unattached vn is handled by the existing size gate + empty glob; attached vn is kept.

Why DragonFly-only (ground truth from nlab)

OS hw.disknames / kern.disks Phantom leak?
DragonFly md1..md126 da0 vn0..3 md0 Yes — 127 md phantoms, ~660 spawns
OpenBSD sd0:<duid>,fd0: No — rd0/cd0 not listed; fd0 errors out
NetBSD sd0 dk0 dk1 No — md0/cd0 not listed; dk wedges already handled

OpenBSD/NetBSD hw.disknames is kernel-curated to attached instances, so pseudo-devices never enter the probe. Filtering rd there would be dead code — and harmful in a bsd.rd recovery boot where rd0 is the root disk. So this change does not touch their code paths; their facts are byte-identical by construction. Ruby Facter has no BSD disks resolver, so there is no parity constraint.

Validation (nlab DragonFly guest)

  • Release gate: green (all facts present).
  • disks = {da0} only — the 127 md phantoms are gone.
  • partitions = /dev/da0s1a (/boot), s1b (swap), s1d (/) — unchanged.
  • Discovery of disks partitions: 1m42s system time → 0.65s.
  • disklabel spawns: ~660 → ~1.

Review

  • OCR (--audience agent): 0 comments.
  • Adversarial review: no correctness findings; one low test-gap (missing positive attached-vn test) was fixed.

Implements OpenSpec change optimize-bsd-disks-probe.

The DragonFly disks/partitions probe spawned disklabel on device+s1..s4 for
every kern.disks device (~660 spawns on a 132-device guest, 127 of them empty
md memory disks) and leaked those md disks into the disks fact as 9.77 MB
phantoms.

- dragonFlyPseudoDisk skips md/cd pseudo-devices (driver class) in both the
  disks list and the partition probe.
- dragonFlyDisklabelTargets now globs the slice nodes that actually exist
  (/dev/<dev>s<N>) instead of the fixed s1..s4, and drops the never-productive
  whole-disk target (the DragonFly label lives on the slice).
- currentDragonFlyPartitions takes s.glob; unattached vn is handled by the
  existing size gate + empty glob, attached vn is kept.

Scope is DragonFly-only: nlab ground truth shows OpenBSD/NetBSD hw.disknames is
kernel-curated to attached instances (no md/rd/cd leak), and filtering rd there
would be harmful in a bsd.rd root boot.

Validated on the nlab DragonFly guest: gate green, disks={da0} only,
partitions unchanged, discovery 1m42s->0.65s, disklabel spawns ~660->~1.
@ncode ncode merged commit c8cac21 into main Jul 1, 2026
37 checks passed
@ncode ncode deleted the juliano/optimize-bsd-disks branch July 1, 2026 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant