Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

das (alte) Problem mit nicht zur Ruhe kommenden Festplatten (bzw. wachen die nach längstens 4 Minuten wieder auf)

Featured Replies

Hallo an die (wissende) Community, ...

Ich habe zwischenzeitlich eine Menge gelesen und mir ist bewusst, dass ich mit Sicherheit noch immer nicht genug über Linux bzw. Unraid und dessen Verhaltensweisen weiß.

Was ich jedoch weiß:

Der Unraid-Server lässt meine Platten partout nicht "schlafen".

Zwar kann ich die manuell in den Spinndown zwingen und manchmal tun sie das auch von selbst, jedoch wachen die IMMER nach längstens 4 Minuten (gemäß Unraid-Log) wieder auf.

Ich weiß auch inzwischen, dass es nicht am Lesen der Smartdaten liegt, sondern diese Logeinträge dann die Folge des Hochfahrens sind (smartctrl-Einträge für jede Platte).

Aufgefallen ist mir lediglich, dass ausschließlich die Array-Platten samt Parity (4 x 16 TB) davon betroffen sind.


Die noch leeren (alten) 2 x 4 TB WD Red im System bleiben immer permanent aus, wenn die mal abgeschaltet haben.

Docker aktuell: "Cloud-Commander" (meist aus), "HW-Monitor" (meist aus), "ollama" und "PlexMedia-Server".

Alle Docker sind für den Test natürlich: AUS

Parity-Check ist : AUS

Externe Zugriffe übers Netz auf das einzig freigegebene Medienverzeichnis finden ebenfalls nicht statt.

Ich habe außerdem die Plugins "File Activity" und "Open Files" installiert, ohne dass bei "File Activity" je irgendwas angezeigt wird.

In "File Activity" bleiben die Listen unter "share activity" und "disk activity" auch nach Stunden schlicht LEER (nein, es sind keine Filter aktiv)! Muss ich da was aktivieren? Übersehe ich da was?

"Open Files" zeigt zwar eine Menge Dateien an.

Diese liegen jedoch auf dem Pfad "/usr/.... oder /mnt/cachepool/ .... etc.

Alle Pfade liegen in jedem Fall ausschließlich auf den beiden SSDs

Außerdem wird in irgendeinem Thread "Fix-Common-Problems" empfohlen, aber was mache/erreiche ich damit?

Im UNRAID-Log stehen keinerlei Informationen darüber, was denn wirklich das Hochfahren bewirkt!

Die Shares abseits meines Medienverzeichnisses liegen ebenfalls ausschließlich auf den SSDs, sprich dem Cachepool, also "Aoostar-x-linux" für das Display des Aoostar, "appdata", "data", "docker", "system" und ein TransCode-Ordner für Plex.

Mein Medienordner "Media_New" ist primär auf dem Cachepool zu Hause, sekundär auf dem Array.
Der Mover Cachepool>>Array läuft laut Sheduler nur alle 4 Stunden, in der Praxis bekommt er höchstens einmal pro Tag tatsächlich Arbeit.

Ich habe neben dem Diagnose-Log mal ein Unraid-Log als "Beweis" angehängt, Aussagen tut das letztere aber, wie gesagt, Null.

Nun die eigentliche Frage an das Schwarmwissen:

Wie bekomme ich zuverlässig raus, wo es hier hakt, was also tatsächlich die Platten weckt?

Irgendwelche aussagekräftige Tools, die ich nutzen soll?

Grüße

Richi aka HuDiNi aka Universal-Dilettant

NAS-Log Array Spinup-smartctl.txt nas-diagnostics-20260906-1157.zip

Edited by HuDiNi
corrections

Solved by alturismo

1 hour ago, HuDiNi said:

Wie bekomme ich zuverlässig raus, wo es hier hakt, was also tatsächlich die Platten weckt?

Irgendwelche aussagekräftige Tools, die ich nutzen soll?

also, mal vorne angefangen

Share Konfigurationen, bis auf den "Transcode" sieht das gut aus, auch wenn Transcode auf SSD leigt sollte der auch so konfigutiert sein, only ...

A-------------x shareUseCache="only" # Share exists on cachepool

appdata shareUseCache="only" # Share exists on cachepool

d--a shareUseCache="only" # Share exists on cachepool

d----r shareUseCache="only" # Share exists on cachepool

M-------w shareUseCache="yes" # Share exists on cachepool, disk1, disk2

system shareUseCache="only" # Share exists on cachepool

T-------e shareUseCache="no" # Share exists on cachepool

dann nutzt du diverse plugins, auch mit "gleicher Funktion", da würde ich mal "aufräumen", die fassen alle auch HDD an

drwxr-x--- 2 root root 9 Sep 6 10:43 automover

drwxr-x--- 2 root root 4 Jul 13 00:07 ca.mover.tuning

drwxr-xr-x 2 root root 6 Sep 2 00:42 activestreams

drwxr-x--- 2 root root 3 Sep 5 16:24 file.activity

drwxr-x--- 2 root root 3 Sep 5 16:25 open.files


-rw-r--r-- 1 root root 7684 Jul 14 23:20 dlandon.cache.dirs.plg

drwxr-x--- 2 root root 4 Aug 22 14:37 dynamix.cache.dirs

dann hast du noch diesen Eintrag in der syslinux gesetzt, für was ? (bzw. weißt du genau dass du es brauchst ;) )

BOOT_IMAGE=/boot@/bzimage acpi_enforce_resources=lax

last but not least ... wahrscheinlich am ehesten die Ursache, du nutzt zfs für die disks im Array ?

zfs hat self tests und self healing und ... wenn ja, nicht wundern bitte ;) das löst sehr gerne spinups aus und ist daher auch nicht die Empfehlung, auch wenn alle Welt sagt "zfs is the best" ...

man mag mich gerne korrigieren.

  • Author

Danke schonmal für deine einleitende Expertise. 😋

Ich habe nun wieder alles runtergeschmissen, was ohnehin zum Teil nur zwecks Bekämpfung der Symptome drauf gekommen ist.

Außerdem habe ich auf den 2 ungenutzten Platten ebenfalls ein Share angelegt und dort 20 GB Daten reingeschaufelt (kleine Files).

Was soll ich sagen:

ZFS alleine kann es nicht sein, denn die kleinen Platten bleiben nach wie vor aus, solange man nicht drauf zugreift (so wie es sein soll), ...

Am Verhalten der großen Platten hat sich bedauerlicherweise absolut nichts verändert.

Können auch die Seagate-Exos-Platten selbst für das Problem sorgen?

Edited by HuDiNi

  • Solution
21 minutes ago, HuDiNi said:

Können auch die Seagate-Exos-Platten selbst für das Problem sorgen?

da die sehr beliebt sind und beispielsweise auch hier im Einsatz sind, eher Nein.

23 minutes ago, HuDiNi said:

ZFS alleine kann es nicht sein, denn die kleinen Platten bleiben nach wie vor aus, solange man nicht drauf zugreift (so wie es sein soll), ...

Am Verhalten der großen Platten hat sich bedauerlicherweise absolut nichts verändert.

dann starte mal im safe mode und schau da, da laufen keine plugins, keine dockers, keine vms, keine Zugriffe

  • Author

Soderla, ...

Im abgesicherten Modus laufen nach dem Start des Arrays (natürlich) auch Docker und die Freigaben sind aktiv, selbst der eingebaute Mover fühlt sich nach dem Start des Arrays sofort gemüßigt in Aktion zu treten.

Alleine die wenigen verbliebenen Plugins meldet das System als nicht existent.

Und was soll ich sagen?

In diesem Zustand und bei beendeten Dockern ist seitens der HDDs (ohne Zugriffe auf Shares, nachdem der Mover mal fertig ist) nun dauerhaft Ruhe im Karton.

Ich werde die (eigentlich empfohlenen) Plugins also mal schrittweise entfernen und weiter berichten.

Edited by HuDiNi

  • Community Expert
3 hours ago, HuDiNi said:

Können auch die Seagate-Exos-Platten selbst für das Problem sorgen?

Als Person mit dutzenden Exos im EInsatz kannich sagen: nein, zumindest meine haben keine Probleme schlafen liegen zu bleiben.

Es muß irgendeine Software/Einstellung sein.

  • Author

Im ersten Schritt habe ich nur die Plugins von Dynamix (s3sleep und systeminfo) rausgeschmissen und nun scheint es tatsächlich zu funktionieren. 😊

Danke vorerst. 🤪

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.