Jump to content

Unraid 6.12.0-RC5 kein Spindown der Platten im Array


Recommended Posts

Hallo zusammen,

 

ich habe hier bei mir auf 6.12.0-RC5 geupdatet, weil ich mir meinen Pool als ZFS eingerichtet habe, das hat auch wunderbar funktioniert.

 

Danach habe ich es vielleicht ein bisschen übertrieben und auch die einzelnen Platten im Array auf ZFS formatiert. Dazu habe ich immer eine leer geräumt (unBalance), formatiert und dann das gleiche bei der nächsten. Das hat auch alles ohne Probleme funktioniert. Jetzt läuft alles unter ZFS.

 

Was mir aber jetzt auffällt, ist, dass die Platten im Array nicht mehr in den Spindown gehen, obwohl eigentlich nichts darauf schreiben sollte. Trotzdem sieht man auf der "Start" Seite immer wieder Lese- und Schreibzugriffe. Selbst das Stoppen aller Docker und der VM hat nichts geholfen. auf den Disks liegen auch nur Sachen, die dort auch liegen sollen (kein appdata, oder so).

Was mir noch auffällt ist eine komische Anzeige des freien Platzes der eingebundenen Netzlaufwerke auf dem Windows PC.

 

Hat jemand von euch evtl. ähnliches beobachtet, vielleicht auch mit XFS Dateisystemen? Kann es am ZFS Dateisystem liegen? Oder ist die RC5 die Ursache?

 

Grüße

Jochen

Datenträger.png

Disk1.png

Freigaben.png

Netzlaufwerke.png

Link to comment
46 minutes ago, Jochen Kklaus said:

Danach habe ich es vielleicht ein bisschen übertrieben und auch die einzelnen Platten im Array auf ZFS formatiert. Dazu habe ich immer eine leer geräumt (unBalance), formatiert und dann das gleiche bei der nächsten. Das hat auch alles ohne Probleme funktioniert. Jetzt läuft alles unter ZFS.

genau genommen bringt Dir ZFS (oder BTRFS) im Array nix, gegenüber XFS - Copy-on-Write detektiert den Fehler, kann ihn aber nicht heilen (mangels alternativem vdev im pool - der eben nur aus einer Disk besteht)...es springt eh die Parity ein.

Im unraid-Pool (primary Storage) macht ZFS sehr viel Sinn.

Edited by Ford Prefect
Link to comment
4 hours ago, Ford Prefect said:

genau genommen bringt Dir ZFS (oder BTRFS) im Array nix, gegenüber XFS - Copy-on-Write detektiert den Fehler, kann ihn aber nicht heilen (mangels alternativem vdev im pool - der eben nur aus einer Disk besteht)...es springt eh die Parity ein.

Im unraid-Pool (primary Storage) macht ZFS sehr viel Sinn.

irgendwo hab ich gelesen, daß ZFS anzeigen kann, bei welcher Datei der Fehler aufgetreten ist, dann ist es leichter die Datei aus einem Backup wiederherzustellen, wenn Parity aus welchen Gründen auch immer mal nicht klappt.

Link to comment
6 minutes ago, Jochen Kklaus said:

wenn Parity aus welchen Gründen auch immer mal nicht klappt.

wenn Parity nicht geht, ist die ganze DIsk futsch, mit allen Dateien da drauf.

 

Zurück zu Deinem Problem: ...oben sieht man das doch eine Daten Disk schäft.

Hast Du mal bei den Shares "alle berechnen" gemacht? sind die Daten, die auf Cache gehören wirklich alle nur auf Cache?

Wo sind die Docker-Images / Container? Da gibt es einen Hinweis, in den 6.12RCx wie man das machen soll, für Docker im Verzeichnisbaum, statt im IMG bei den Docker Einstellungen.

Link to comment
32 minutes ago, Ford Prefect said:

wenn Parity nicht geht, ist die ganze DIsk futsch, mit allen Dateien da drauf.

 

Zurück zu Deinem Problem: ...oben sieht man das doch eine Daten Disk schäft.

Hast Du mal bei den Shares "alle berechnen" gemacht? sind die Daten, die auf Cache gehören wirklich alle nur auf Cache?

Wo sind die Docker-Images / Container? Da gibt es einen Hinweis, in den 6.12RCx wie man das machen soll, für Docker im Verzeichnisbaum, statt im IMG bei den Docker Einstellungen.

ja, die eine schläft manchmal 😀aber nicht lange.

Alle berechnen hab ich schon gemacht, auch mit dem Filemanager und in der Konsole geschaut, alle Dateien sind richtig, glaube ich 🙂 Auf den Festplatten sind keine System, appdata oder domain Ordner zu finden.

Docker habe ich auf Verzeichnis umgestellt, das liegt im share system. Wie du oben siehst habe ich für System, appdata, domain (VM) und noch einen Ordner mit den Datenbanken den Primärspeicher auf Cache umgestellt und den Sekundärspeicher auf keine.

 

Ich hab jetzt im Syslog (im Auszug ganz unten) gesehen, dass immer wieder "read SMART" Befehle ausgeführt werden, kann das die Platten aufwecken?

system.png

syslog.txt

Link to comment
7 hours ago, Jochen Kklaus said:

ich habe hier bei mir auf 6.12.0-RC5 geupdatet, weil ich mir meinen Pool als ZFS eingerichtet habe, das hat auch wunderbar funktioniert.

 

Ich habe eines meiner Systeme auch seit kurzem auf RC5, im Array alles auf xfs in den Multidevice Pools aber zfs.

 

Im Array (xfs) legt sich alles brav schlafen.

 

Wie ich schon ein paar mal erwähnte habe ich auch das Problem, dass sich meine zfs Pools (auch schon bei vorherigen RC) alle nicht mehr schlafen legen/schlafend bleiben, selbst wenn ich manuell spindown mache.

 

Bisher vermute ich irgendeine Software/Plugin als Ursache, da andere andeuteten, dass deren zfs formatierten Datenträger sich schlafen legen. Ich habe sie aber noch nicht gefunden.

 

Link to comment
7 hours ago, DataCollector said:

 

Ich habe eines meiner Systeme auch seit kurzem auf RC5, im Array alles auf xfs in den Multidevice Pools aber zfs.

 

Im Array (xfs) legt sich alles brav schlafen.

 

Wie ich schon ein paar mal erwähnte habe ich auch das Problem, dass sich meine zfs Pools (auch schon bei vorherigen RC) alle nicht mehr schlafen legen/schlafend bleiben, selbst wenn ich manuell spindown mache.

 

Bisher vermute ich irgendeine Software/Plugin als Ursache, da andere andeuteten, dass deren zfs formatierten Datenträger sich schlafen legen. Ich habe sie aber noch nicht gefunden.

 

...habe ich auch so, allerdings bin ich noch auf RC2.

Mein zpool im unraid-pool schläft einwandfrei....Array mit xfs auch.

7 hours ago, DataCollector said:

War das bisher nicht anders herum? Wenn die Festplatte aufwacht/wach ist werden die Smartwerte ausgelesen?

Äh...OK, ja, dann ist das der "Indikator", dass die Platte geweckt wurde. Ein "spinning up Disk vorher gibt es ja nicht" .

Der Effekt ist aber der Gleiche und beim TE viel zu häufig...da muss ja ein Grund vorliegen, wenn vor RCx alles ruhig(er) war.

Link to comment
On 5/6/2023 at 9:16 AM, Jochen Kklaus said:

hab ich gemacht, mal sehen, was an Rückmeldung kommt.

Leider kam auch in dem Bug-Report Faden bisher kein Hinweis, der geholfen hat.

Ich sollte, Unraid auf die letzte 6.11er Version zurück zu setzen (Backup auf den Stick aufgespielt), nach dem reboot können die Laufwerke dann erst mal nicht gemounted werden (wegen ZFS), dann habe ich wieder das Update durchgeführt. Leider besteht das Problem weiterhin.

 

Mein Problem könnte sein, dass ich mit 6.12.0-RC2 "neue Konfiguration" ausgeführt habe und seitdem scheint etwas falsch zu laufen.

Ich überlege jetzt den Cache noch einmal leer zu räumen und neu zu erstellen, könnte das helfen?

Was mir noch komisch vorkommt ist die Ausgabe von "df" auf der Konsole, die habe ich als Textdatei mit angehängt. Sieht das bei euch ähnlich aus?

 

Ansonsten wird mir wohl nichts anderes übrig bleiben als auf RC6 oder die fertige 6.12 zu warten.

 

Gruß

Jochen

Ausgabe df.txt brutus-diagnostics-20230509-1755.zip

Link to comment
  • 1 month later...

Ich bin ganz neu in Unraid, hab gerade 6.12.1 laufen.

In meinem Array ist das selbe Problem, die 4 in zfs formatierten array Disks gehen auch nicht in den Spindown. Könnte also ein Bug sein bei Arrays mit ZFS Datenträgern.

Edit: ich habe rausgefunden, dass die Disks runterfahren und auch aus bleiben, jedoch nach dem login auf die Weboberfläche sofort hochfahren. Ich vermute einen Zusammenhang mit dem Smart öesen um die temperatur anzuzeigen. log der disk

Jun 30 01:48:45 datascotty emhttpd: spinning down /dev/sdd <- korrekter spindown nach eingestellter Zeit
Jun 30 04:20:22 datascotty emhttpd: read SMART /dev/sdd <- hier ist die disk hochgefahren, ein paar Sekunden nach den Login in die webgui

Edited by KnustKnut
Link to comment
4 hours ago, KnustKnut said:

Könnte also ein Bug sein bei Arrays mit ZFS Datenträgern.

Edit: ich habe rausgefunden, dass die Disks runterfahren und auch aus bleiben, jedoch nach dem login auf die Weboberfläche sofort hochfahren. Ich vermute einen Zusammenhang mit dem Smart öesen um die temperatur anzuzeigen. log der disk

Jun 30 01:48:45 datascotty emhttpd: spinning down /dev/sdd <- korrekter spindown nach eingestellter Zeit
Jun 30 04:20:22 datascotty emhttpd: read SMART /dev/sdd <- hier ist die disk hochgefahren, ein paar Sekunden nach den Login in die webgui

Ich hatte Probleme mit ständig laufenden Datenträgern in zfs als Pool unter den früheren -RC. Aber seit -RC8 glaube ich ist das Problem bei mir verschwunden. Ab und zu laufen die zwar immer noch von selbst an und werkeln da irgendetwas, aber das ist wohl die "Magie" von zfs.

Überwiegend sehe ich die Festplatten schlafend angezeigt.

 

SMART weckt im Normalfall Festplatten nicht auf. Wenn Festplatten aufwacken wird aber Smart (auch Temperatur) gelesen, so daß gerne die Ursache auf SMART geschoben wird, weil das bei aufwachenden Festplatten die erste verzeichnete Aktion im Log ist.

 

 

Link to comment

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...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...