Work Intent: Stop the temperature metrics query from spinning up array disks (#2017) #2090

Overview

Fix #2017. Reading disk temperatures through the metrics { temperature } query wakes every spun-down array disk. On my server (Unraid 7.3, five HDDs in the array) one request took about 50 seconds and spun up all five disks. Anything that polls temperatures, including the systemMetricsTemperature subscription, keeps the array from ever staying spun down.

The cause: DiskSensorsService.read() gets its disk list from DisksService.getDisks(), which calls diskLayout() from systeminformation. On Linux, diskLayout() runs smartctl -a -j and smartctl -H on every disk without -n standby, and that wakes them. The temperature read itself (getTemperature()) already uses smartctl -n standby, so the disk listing is the only part that wakes the disks.

To confirm the cause before asking, I tried a small local prototype and measured both paths on my server with the disks spun down:

Technical Approach

• Add DisksService.getPhysicalDisks(), which lists disks with lsblk -J -d -b -o PATH,TYPE,SIZE,SERIAL,MODEL,TRAN. lsblk only reads kernel metadata and never touches the disk.
• It returns the same id (serial), device, name (model) and interfaceType that the temperature code uses today, so sensor IDs and names don't change. It keeps whole disks with a non-zero size and skips loop/ram devices, which matched what diskLayout() returned on my server.
• Switch DiskSensorsService.read() to use it. Spun-down disks are then skipped by the existing smartctl -n standby check, as they are today, instead of being woken.
• Move the interface-type mapping in parseDisk() into a small shared helper so both paths map it the same way.
• Tests: unit tests for getPhysicalDisks() (parsing, filtering, no SMART calls), and a sensor test that read() no longer calls getDisks().

Out of scope: getDisks() (the disks query) has the same wake-up behavior through diskLayout(). I'd keep this change small and raise that separately if you want it fixed too.

Scope

• API
• Plugin
• Web UI
• Build/Deploy Process
• Documentation

Timeline & Impact

• Estimated time needed: a few days, since the prototype and tests already exist.
• Potential impacts: temperature readings only. Spun-down disks won't report a temperature, as with the current -n standby behavior. No schema changes.

Pre-submission Checklist

• I have searched for similar work/issues
• I understand this needs approval before starting
• I am willing to make adjustments based on feedback