DisksService.getDisks wakes spun-down array disks via systeminformation.diskLayout()

Start in api/src/unraid-api/graph/resolvers/disks/disks.service.ts at getDisks(), then compare its diskLayout() path with getTemperature() and the WebUI's SmartInfo.php behavior. Exercise /graphql with { disks { id } } against standby disks; done means identity is returned without waking them and smartStatus remains unknown for disks that are still asleep.

Environment

Unraid OS Version: 7.3.1

Are you using a reverse proxy? No (tested directly against the LAN IP and via the LAN hostname; reproduction does not involve any proxy).

Pre-submission Checklist

• I have verified that my Unraid OS is up to date
• I have tested this issue by accessing my server directly (not through a reverse proxy)
• This is not an Unraid Connect related issue (if it is, please submit via the support form instead)

Issue Description

Querying { disks { ... } } over the unraid-api GraphQL endpoint spins up array drives that were in standby. The resolver populates each Disk via systeminformation.diskLayout(), which on Linux runs smartctl -H and smartctl -a -j per device (systeminformation 5.31.7, lib/filesystem.js), without the -n standby flag. Modern large HDDs (Seagate Exos ≥16 TB, WD Gold ≥16 TB, etc.) treat the resulting ATA commands as a wake-up signal and leave standby.

Note that the same file's getTemperature(device) already does the right thing on line 104:

const { stdout } = await execa('smartctl', ['-n', 'standby', '-A', '-j', device]);

That is exactly the call shape we need everywhere else in this service.

The relevant code in api/src/unraid-api/graph/resolvers/disks/disks.service.ts:378 (unchanged on main as of this edit):

async getDisks(): Promise<Disk[]> {
    const partitions = await blockDevices().then((devices) =>
        devices.filter((device) => device.type === 'part')
    );
    const arrayDisks = this.configService.get<ArrayDisk[]>('store.emhttp.disks', []);
    const { data } = await batchProcess(await diskLayout(), async (disk) =>
        this.parseDisk(disk, partitions, arrayDisks)
    );
    return data;
}

The official WebUI (/usr/local/emhttp/plugins/dynamix/include/SmartInfo.php) already avoids this: identity comes from cached disks.ini populated by emhttpd at boot, and any smartctl invocation passes -n standby. That is why opening Main on the WebUI never wakes drives but a GraphQL { disks { ... } } does.

Steps to Reproduce

1. Spin down the array disks via the WebUI or hdparm -y /dev/sdX.
2. Confirm they are sleeping: smartctl -n standby -i /dev/sdX → Device is in STANDBY mode.
3. Issue a minimal GraphQL query through /graphql:

   { disks { id } }
   

4. Re-check the larger drives: smartctl -n standby -i /dev/sdX.
5. The ≥16 TB drives that reported STANDBY mode in step 2 now report Power mode. Field selection in the query is irrelevant: even { disks { id } } is enough because the resolver fully populates each disk via diskLayout() before returning.

Expected Behavior

GraphQL queries against disks, and everything else that goes through DisksService.getDisks() (disk(id), assignableDisks, the onboarding Internal Boot step via getAssignableDisks() / getInternalBootDevices(), and the disk temperature sensors), should not transition any drive out of standby. Identity fields (vendor, model, serialNum, firmwareRevision, interfaceType, size, type) should come from kernel metadata, and smartStatus should be probed only for drives that are already spinning, matching the WebUI's behavior.

Actual Behavior

Test data from one server (mixed array, single query of { disks { id } } from a fully spun-down baseline):

Disk	Model	Size	After { disks { id } }
/dev/sda	WDC WD160EDGZ	16 TB	Spun up
/dev/sdb	WDC WD180EDGZ (parity)	18 TB	Spun up
/dev/sdd	WDC WD30NPRZ	3 TB	Still standby
/dev/sde	WDC WD40EZRX	4 TB	Still standby
/dev/sdf	WDC WD180EDGZ	18 TB	Spun up
/dev/sdg	ST16000NM000J	16 TB	Spun up
/dev/sdh	ST16000NM000J	16 TB	Spun up

Pattern: large modern drives wake on any ATA command; older smaller drives ignore it. Consistent with current Seagate / WD firmware behavior.

Additional Context

Suggested fix. Replace diskLayout() with a custom enumeration that mirrors the WebUI strategy:

• Use lsblk -d -b -J -O for identity. It is sysfs-backed with no SMART access. -b matters: without it size comes back as a string like "931.5G" instead of bytes (systeminformation itself calls lsblk -ablJO).
• Map each lsblk device to the shape diskLayout() returned (device, name, vendor, serialNum, firmwareRevision, interfaceType, size, type as HD / SSD / NVMe from rota and tran), so parseDisk can stay as it is. lsblk reports vendor: "ATA" for SATA drives, so the vendor is better derived from the model string in that case.
• Use smartctl -n standby -H -j /dev/sdX per disk for smartStatus. Treat exit code 2 as "standby, status unknown".
• Keep blockDevices() for partitions.

#2091 adds a DisksService.getPhysicalDisks() built on lsblk -b for the temperature sensors; the fix above could build on it once it lands.

Reference implementation. I have implemented this pattern as a runtime monkey-patch in u-manager-companion (function patch_disks_service_bundle) and verified on the same server that:

• { disks { ... } } returns the full record (vendor / serial / firmware / interfaceType / size) and smartStatus: "UNKNOWN" for spun-down disks.
• No drive in standby transitions to active.
• Latency drops from several seconds to <500 ms because we no longer wait on smartctl for every device.

Happy to open a PR with the upstream version of the same change.