/api/storage now runs a single `zpool status -j --json-int -P` (OpenZFS
2.3+) for all pools and returns, per pool:
- top-level vdevs with type, raidz/draid parity, class (data, special,
dedup, log, cache, spare), state and read/write/checksum errors
- member devices with path, resolved base disk, state, error counters,
slow I/Os, and the spare-N/replacing-N they sit under while swapping
- scrub/resilver status (progress only while running), the pool's
status/action text and data-error count
- fragmentation, capacity and dedup ratio from `zpool list`
This replaces the per-pool `zpool status` text loop whose result
(zfs_disks) was never used. Member paths (by-id, by-partlabel, wwn) are
resolved to base disks via sysfs rather than an lsblk call per device.
On ZFS without `-j`, pools report details_available: false and the UI
falls back to the existing basic card.
The ZFS pool card shows a layout summary (e.g. "RAIDZ2 | 5 disks |
Scrub finished ...") and opens a details dialog with the vdev tree,
per-device error counts, scrub/resilver progress, and links from each
member disk to its disk details dialog.
Tested against `zpool status -j` output from PVE 9 / OpenZFS 2.4.4:
mirror, raidz2, striped mirrors, single-disk pool, and a file-backed
degraded raidz1 with log, cache and spare devices.
Tests cover the `zpool status -j` -> Storage view shape against real
output from PVE 9 / OpenZFS 2.4.4 hosts (serials and WWNs replaced):
mirror, raidz2, single-disk pool, slow I/Os, and a degraded raidz1 with
log, cache and spare devices; plus a synthetic resilver with a spare
swapping in. Member path -> base disk resolution is tested against a
stubbed sysfs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each disk in /api/hardware now carries a controller_slot, resolved from
the disk's sysfs device path: the deepest PCI address in that path is the
controller (bridges sit above it), normalised to lspci's slot format so it
matches pci_devices[].slot directly. NVMe falls back to the controller's
own sysfs link when the namespace resolves to a subsystem with no PCI
parent; zvols and other virtual devices get None.
Hardware page:
- The disk dialog shows its storage controller (click through to the
controller), and the PCI device dialog lists the disks attached to it.
- Storage controllers in the PCI Devices list get a badge with the
number of attached disks.
Storage view:
- /api/storage returns controller_slot on each physical disk plus a
controllers map (slot -> class, vendor, device, subsystem name,
driver), built from the cached `lspci -vmm` output so the Storage view
doesn't need the heavier /api/hardware enumeration.
- "Physical Disks & SMART Status" can group disks under their storage
controller, with a header showing the controller name, slot, driver
and disk count. Groups follow PCI slot order; disks with no resolvable
controller are listed last. USB disks keep their own section.
- The disk details dialog shows the storage controller on the Overview
tab.
- Grouping is opt-in via a new Storage Display card in Settings, stored
per browser (localStorage) and synced across open views, following the
existing nav-tab-order preference pattern. Off by default.
Also:
- Treat "IDE interface" as a storage controller, so SATA controllers left
in BIOS IDE mode (e.g. Intel 7 Series, ata_piix) appear in pci_devices
and disks behind them can be mapped.
- lspci prints "Device xxxx" when it has no subsystem name; that
placeholder is ignored so the chip name is shown instead.
- Add the missing sdevice field to the PCIDevice type.
Tests cover the sysfs path -> controller slot rule against real paths
from two PVE 9 hosts (SAS HBA, AHCI SATA, SATA in BIOS IDE mode, USB
behind a hub, NVMe behind chipset bridges), the non-zero PCI domain case
(Intel VMD), the NVMe multipath fallback, and get_storage_controllers'
lspci parsing including the "Device xxxx" placeholder and driver lookup.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VAIO73
github-actions[bot]
MacRimi
ProxMenuxBot
MacRimiandGitHub
DrOwlandClaude Opus 5.5