Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,105 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
64/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux, typescript
Ambito
api, operating-systems, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
TypeScript
Stelle
113
Fork
23
Merge medio
1g 21h
PR unite (30g)
12

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di unraid/api

Tutte le issue di unraid/api

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.