Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Work Intent: Stop the disks query from spinning up array disks (#2018)

Open
  • Is something wrong?
#2,105 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
64/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, typescript
Domain
api, operating-systems, performance

Research direction

Start in disks.service.ts at getDisks(), then read getPhysicalDisks(), parseDisk(), and blockDevices() to understand the current disk shape and partition handling. Run the existing disk-service tests before adding coverage for lsblk mapping, smartctl standby status, device filtering, and ensuring diskLayout() is no longer called. Done means disk-list queries avoid waking standby disks while preserving the expected disk fields and status behavior.

Written by the indexing model from the issue text.

Description

Overview

Fix #2018. Any query that goes through DisksService.getDisks() wakes every spun-down array disk: disks, disk(id), assignableDisks and the onboarding Internal Boot step (getAssignableDisks() / getInternalBootDevices()). Even { disks { id } } is enough. Anything that polls the disk list keeps large drives from staying in standby.

The cause is the same one #2090 / #2091 found for temperatures: getDisks() builds its list from diskLayout() in systeminformation, which on Linux runs smartctl -a -j and smartctl -H on every disk without -n standby.

I've been running the approach below as a runtime patch on my own server (Unraid 7.3, mixed array with 16 and 18 TB drives) for a few months. With the disks spun down, { disks { id } } spins up every large drive on stock, and none with the patch. The query also goes from several seconds to under 500 ms.

Technical Approach

  • Replace diskLayout() in getDisks() with a listing from lsblk -d -b -J -O, which only reads kernel metadata. Ideally this builds on getPhysicalDisks() from #2091 once it lands, adding the columns getDisks() needs (vendor, firmware revision, rotational) so there is a single place that lists disks.
  • Map each device to the shape diskLayout() returns today, so parseDisk() stays as it is: device, name (model), vendor, serialNum, firmwareRevision, interfaceType (from tran), size in bytes, and type as HD / SSD / NVMe (from rota and tran, same values diskLayout() returns). lsblk reports vendor: "ATA" for SATA drives, so in that case the vendor is derived from the model string.
  • Get smartStatus from smartctl -n standby -H -j <device>. Exit code 2 means the disk is in standby and was not queried, which maps to UNKNOWN.
  • Keep blockDevices() for partitions.
  • Tests: unit tests for the lsblk mapping (size in bytes, drive type, vendor fallback, filtering out loop/ram devices) and for the smartctl status mapping, plus a test that getDisks() no longer calls diskLayout().

Out of scope: the geometry fields on Disk (bytesPerSector, totalSectors, etc.) are non-nullable but diskLayout() already returns null for them on Linux, so selecting them errors today. This change would leave them as they are; happy to look at that separately.

Scope

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

Timeline & Impact

  • Estimated time needed: a few days, since the logic already runs as a patch and mostly needs porting and tests. I'd start after #2091 is merged to avoid conflicts in disks.service.ts.
  • Potential impacts: smartStatus becomes UNKNOWN for disks in standby instead of waking them to read it. 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
Dominant language
TypeScript
Stars
113
Forks
23
Avg merge
1d 21h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from unraid/api

All issues in unraid/api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.