Community-Lösung

ZimaOS-HDD-Standby funktioniert nicht: Finden Sie heraus, was die Festplatten wachhält, und verstehen Sie die Fehlerbehebungen in 1.3.2 und 1.6.0

A January 2025 ZimaCube thread where six RAID5 HDDs never entered a configured 20-minute standby state even after Docker apps were stopped. IceWhale acknowledged the issue, documented upcoming 1.3.2 storage-health/cache changes, and provided commands to identify processes accessing the disks. ZimaOS 1.6.0 later fixed another wake source caused by smartd.

Diese Quelle ist aussagekräftiger als eine allgemeine Beschwerde wie „Meine Laufwerke gehen nie in den Ruhezustand“, da IceWhale sowohl einen Plan zur Produktverbesserung als auch eine Diagnosemethode bereitstellte. Die sechs RAID5-HDDs blieben aktiv, selbst nachdem Docker-Anwendungen beendet worden waren. Daher konzentrierte sich die Untersuchung auf die Speicher- und Zustandsüberwachungsdienste von ZimaOS sowie auf mögliche Aktivitäten auf Kernel-Ebene.

ZimaOS 1.3.2 reduzierte daraufhin unnötige Festplattenabfragen und verbesserte das Standby-Verhalten. Deutlich später behob ZimaOS 1.6.0 ein weiteres konkretes Problem, bei dem smartd schlafende Festplatten sporadisch aufweckte. Diese Versionen beheben bekannte Ursachen für das Aufwachen. Wenn eine aktuelle Festplatte jedoch weiterhin aktiv bleibt, kann sie von einer anderen App, einem Backup, einem Indexer, einer Dateisystemaufgabe, einer USB-Bridge oder einem Kernel-Dienst angesprochen werden.

ZimaOS-Systemmonitor mit kontinuierlichen I/O-Zählern auf mehreren HDD-Geräten während der Fehlerbehebung des Standby-Problems
Der Nutzer beobachtete auf mehreren HDDs Aktivität, selbst nachdem die Anwendungslast reduziert worden war.

IceWhale änderte die Speicherabfragen in ZimaOS 1.3.2

orca-zhang beschrieb drei konkrete Optimierungen, die für Version 1.3.2 geplant waren:

  • eine einfachere Logik für Zustandsprüfungen;
  • die Aktualisierung des Festplattendaten-Caches nur, wenn eine Änderung der Festplatte erkannt wird;
  • keine Abfrage von Informationen wie Temperatur oder Betriebszeit bei einer Festplatte, die sich bereits im Standby befindet.

Der Grund dafür ist wichtig: Einige HDDs oder Controller können solche Abfragen nicht aus dem Cache beantworten. Die Abfrage von Zustandsdaten weckt daher die physische Festplatte auf.

Die aktuellen Versionshinweise zu 1.3.2 fassen diese Änderungen als Reduzierung unnötiger Lese-/Schreibaktivität und Verbesserung des Festplatten-Standbys zusammen.

IceWhale stellte eine Abfrage für Prozesszugriffe bereit

Die offizielle Antwort schlug vor, Prozesse zu ermitteln, die derzeit ein Dateisystem oder Gerät geöffnet haben:

for pid in $(fuser -m <device_path> 2>/dev/null); do
  ps -p $pid -o comm=
done | uniq

Ersetze <device_path> durch den tatsächlichen Pfad zur Festplatte oder zum eingebundenen Speicher. Dieser Befehl dient der Diagnose und ist nicht destruktiv.

IceWhale schlug außerdem vor, Speicher- und Dateidienste vorübergehend zu beenden

Zur Fehlerbehebung wurde vorgeschlagen, den Standby nach dem Beenden der folgenden Dienste zu testen:

systemctl stop zimaos-local-storage
systemctl stop icewhale-files

IceWhale warnte, dass Teile der Einstellungen und der Dateien-App nicht mehr funktionieren würden, solange diese Dienste beendet sind. Verwende dies nur als kontrollierten Diagnosetest und starte die Dienste anschließend neu oder führe einen Neustart durch.

ZimaOS 1.6.0 behob eine weitere bekannte Ursache für das Aufwecken

Das offizielle Änderungsprotokoll von Version 1.6.0 enthielt später eine separate Fehlerbehebung: Festplatten konnten nicht normal in den Ruhezustand wechseln, weil der Dienst smartd sie sporadisch aufweckte.

Siehe die offizielle smartd-Fehlerbehebung für den Standby.

Das Verschieben von AppData auf NVMe garantiert nicht, dass die HDDs inaktiv bleiben

Der Nutzer hatte die Docker-Datenbanken bereits auf NVMe verschoben. HDDs können dennoch durch Medienscans, Backups, Miniaturansichten, SMB-Clients, SMART-Prüfungen, RAID-/Paritätsaufgaben, die Dateisuche oder einen Prozess angesprochen werden, der einen Pfad geöffnet hält.

Verwende konkrete Zugriffsnachweise, statt anzunehmen, dass das Array keinerlei I/O aufweist, nur weil „alle Apps auf NVMe liegen“.

RAID5 kann eigene Hintergrundaktivität verursachen

Paritätsprüfungen, Wiederherstellungen, Scrubs, Dateisystem-Metadatenaktivität und Überwachung können legitim auf jedes Mitglied zugreifen. Stelle sicher, dass das RAID nicht gerade einen lang andauernden Wartungsvorgang ausführt, bevor du das Standby-Problem untersuchst.

Aktuelles ZimaOS sollte getestet werden, bevor alte Workarounds für Dienste angewendet werden

Die aktuelle ZimaOS-Version ist 1.7.1 und enthält nach diesem Bericht vom Januar 2025 mehrere Jahre an Änderungen an der Speicherverwaltung. Reproduziere das Problem zunächst mit der aktuellen Version und ermittle anschließend die Ursache für das Aufwecken. Deaktiviere Zustands- oder Speicherdienste nicht dauerhaft, nur um das Herunterfahren der Festplatten zu erzwingen.

FAQ zum Festplatten-Standby

Hat IceWhale das Standby-Problem in der Quelle bestätigt?

Ja. Mitarbeiter erklärten, dass das Problem untersucht werde, und dokumentierten Optimierungen für Version 1.3.2.

Kann das Prüfen der Festplattentemperatur oder des Festplattenzustands manche Laufwerke aufwecken?

Ja. IceWhale erklärte ausdrücklich, dass einige Laufwerke ohne zwischengespeicherte Informationen durch eine Abfrage aufwachen können.

Wurde smartd später als weitere Ursache für das Aufwecken identifiziert?

Ja. ZimaOS 1.6.0 behob ausdrücklich sporadische Aufweckvorgänge durch smartd, die den normalen Ruhezustand verhinderten.