Wanjohi f32db5393b fix(nesdoctor): APFS volumes share one pool, and were counted eleven times ...

Found by reading what the macOS CI runner prints, which is the whole reason
that step was added an hour ago. First time anyone had looked at what these
probes return on a platform that is not this laptop:

  /                          96 GiB free of 320 GiB
  /System/Volumes/VM         96 GiB free of 320 GiB
  /System/Volumes/Preboot    96 GiB free of 320 GiB
  /System/Volumes/Update     96 GiB free of 320 GiB
  /System/Volumes/Data       96 GiB free of 320 GiB
  11 filesystems · 483 GiB free of 1600 GiB total

On a machine with 320 GiB. An APFS container presents each volume as its own
filesystem with its own `/dev/diskNsM`, so the device-name dedupe -- which
correctly collapses btrfs subvolumes -- cannot see that the space is shared.

Two changes.

`/System/Volumes` and `/private/var/vm` are skipped: they are not user storage,
and on a Mac they are most of the rows.

And filesystems are deduped by *pool* as well as by device. Two filesystems
reporting byte-identical capacity and byte-identical free space are one store,
whatever their device names say -- which also covers bind mounts and
thin-provisioned LVM, neither of which the device check catches either. Two
genuinely separate disks agreeing to the byte on both figures would cost one
row; a storage total inflated fivefold is a number a capacity plan gets built
on.

Simulated against the exact runner output: eight rows and 2560 GiB become one
row and 320 GiB.

The Windows runner, by contrast, was correct first time -- `C:` and `D:` are
genuinely separate and totalled 179 GiB free of 299 GiB. Worth recording that
the reason we know is that we looked, rather than that we reasoned about it.

2026-09-02 16:16:09 +03:00

24 KiB

Raw Blame History

View Raw