Environment
Unraid OS Version: 7.3 (Unraid OS)
Are you using a reverse proxy? No
Pre-submission Checklist
Issue Description
Calling the metrics GraphQL query to fetch temperature data triggers a spin-up of all array disks. The first request after disks have spun down takes ~5 seconds to respond because it waits for every disk to spin up. Subsequent requests are fast since the disks are already active.
This affects any application that polls temperature data periodically (e.g., monitoring dashboards), as each poll cycle causes unnecessary disk spin-ups, increasing wear, power consumption, and noise.
Steps to Reproduce
- Ensure all array disks are in a spindown (sleep) state.
- Execute the following query against the GraphQL API:
query {
metrics {
temperature {
summary {
average
hottest { name, current { value, status } }
}
}
}
}
- Observe that the response takes several seconds and all array disks spin up during the request.
Expected Behavior
Temperature data comes from hardware sensors (e.g., lm-sensors, /sys/class/thermal/) and should be completely independent of array disk I/O. The query should return quickly regardless of whether disks are spun down.
Actual Behavior
All array disks are woken up during the temperature query. The first request after spin-down takes approximately 5 seconds to complete, as it waits for every disk to spin up before returning a response.
Additional Context
Questions:
- Does the temperature endpoint iterate over array disks for some reason? Could it use a sensor-only path that
doesn't trigger disk access?
- Is there a way to fetch temperature data without waking disks (e.g., reading from a cached value or a daemon that polls sensors independently)?
Environment
Unraid OS Version: 7.3 (Unraid OS)
Are you using a reverse proxy? No
Pre-submission Checklist
Issue Description
Calling the metrics GraphQL query to fetch temperature data triggers a spin-up of all array disks. The first request after disks have spun down takes ~5 seconds to respond because it waits for every disk to spin up. Subsequent requests are fast since the disks are already active.
This affects any application that polls temperature data periodically (e.g., monitoring dashboards), as each poll cycle causes unnecessary disk spin-ups, increasing wear, power consumption, and noise.
Steps to Reproduce
query {
metrics {
temperature {
summary {
average
hottest { name, current { value, status } }
}
}
}
}
Expected Behavior
Temperature data comes from hardware sensors (e.g., lm-sensors, /sys/class/thermal/) and should be completely independent of array disk I/O. The query should return quickly regardless of whether disks are spun down.
Actual Behavior
All array disks are woken up during the temperature query. The first request after spin-down takes approximately 5 seconds to complete, as it waits for every disk to spin up before returning a response.
Additional Context
Questions:
doesn't trigger disk access?