HDD S3 Sleep Modus

[flinx01]

Hallo zusammen,

ich setzte Unraid seit inzwischen einigen Wochen ein, funktioniert auch wie es soll, bis auf ein paar Kleinigkeiten.

Eine der Vorteile von Unraid ist ja, das die HDDs im Arry durch die Cache Festplatten ja selten genutzt werden, so habe ich es wenigstens verstanden. D. H. im Betrieb werden die Datenplatten wenn nicht genutzt schlafen gelegt, damit wird Strom und Lebensdauer optimiert, hab ich zumindest so verstanden 😁.

Was ich jedoch bis jetzt Vermisst habe eine Anzeige in welchem Betriebsmodus die Platten sind, das einzige was ich gefunden habe ist per Shell und HDParm und per Datenträgerprotokoll wo nichts sagend einfach jedesmal drinsteht: 

z. B.: Sep 25 12:48:39 bigone s3_sleep: included disks=sdb sdc sdd sde sdg

Wobei das schon nicht stimmen kann, da SDB + SDC ja das CACHE System ist und nicht aus nomalen HDD besteht.

Verstehe ich das nur nicht ?? Oder hat jemand einen erhelenden Tipp .. 🤔

 

Danke .....

[matty2k]

Also bei mir wird sowohl auf dem Main Tab als auch auf dem Dashboard der Status der einzelnen Laufwerke angezeigt. Sowohl mit dem grünen/grauen Punkt vor dem jeweiligen Laufwerk als auch textlich wie bspw. active/standby.

[flinx01]

Danke für die Antwort,

 

bei mir steht der Status immer auf active, auf Standby nur wenn ich manuell auf den Standby Modus gehe und auch nur bei einer HD im Array.

Kann es sein, das ich irgendeine Freigabe oder Systemverzeichnisss nicht auf dem Cache stehen habe ?

Ich werde mir das mal morgen ansehen , danke noch mal ...

[mgutt]

50 minutes ago, flinx01 said:

Kann es sein, das ich irgendeine Freigabe oder Systemverzeichnisss nicht auf dem Cache stehen habe ?

Kann durchaus sein. Einfach bei den Shares rechts aufs Icon klicken und die Location prüfen. Da muss dann Cache stehen und keine Disk.

 

Auch die Frage, ob du in den Disk Settings das Delay gesetzt hast?!

[flinx01]

So , ich habe alle Freigaben kontrolliert: 

Und auch die Einstellungen in den Disk Settings, dort stand allerdings das Delay auf nie ! Das habe ich jetzt auf 15 Minuten gesetzt.

Die Einstellungen in den einzelnen Laufwerken steht Spin Down Verzögerung : Benutzte Standard.

War das vielleicht der Fehler ? Ich werde das mal so laufen lassen und schauen ...

 

[mgutt]

4 hours ago, flinx01 said:

War das vielleicht der Fehler ?

Ja. Standardmäßig gehen sie nicht schlafen.

[flinx01]

Sorry für die späte Rückmeldung, aber Urlaub ist leider vorbei 😞.

Was für Einstellungen sind den notwendig, bzw., wo kann ich das nachlesen, welche Einstellungen notwendig sind um die HDDs in den Sleepmodus zu schicken ?

 

Bis jetzt ist der Status der, das von den beiden Datenplatten nur die und auch nur selten in den Sleepmodus geht , welche praktisch nicht genutzt wir ....

Ich habe auch alle Freigaben kontrolliert, die stehen alle auf : Ja: cache.

 

Hat jemand eine Idee ??

[jj1987]

In den Festplatten-Einstellungen muss spindown aktiviert sein, ggfs extra je Festplatte.

Erst wenn alle Festplatten im spindown sind beginnt überhaupt erst der Timer.

Die weiteren Kriterien legst du dann im eigentlichen Plugin fest. Z.b ob Netzwerkaktivität den sleep verhindert, oder z.b. wenn ein bestimmter Client online ist.

Und dann wäre der Eingangs erwähnte Timer. Ich glaube standardmäßig sind 30 Minuten eingestellt?! Also Zeit x bis die Festplatten in den spindown gehen, plus dann noch Mal der festgelegte wert im Plugin in der KEINE Aktivität sein darf

[flinx01]

Hmm, alle Platten haben eine Verzögerung von 15 Min. eingetragen,  aber kein Effect.

Ihc habe die Screenshots der Einstellungen angehängt.

 

Wenn ich jedoch den Schalter SPin-Down unter Start bestätige, werden alle HDDs versucht in den Sleep Modus zu schicken, was aber nur mit der 2. Datenplatte funktioniert :

 

....

[Ford Prefect]

On 9/26/2021 at 7:22 PM, flinx01 said:

z. B.: Sep 25 12:48:39 bigone s3_sleep: included disks=sdb sdc sdd sde sdg

...willst Du jetzt HDD spindown oder S3-Sleep für den ganzen Host?

 

Wenn Die HDD nicht in den spindown geht, dann liegt es evtl daran, dass ein Docker oder eine VM dort noch aktiv ist...evtl. liegen dessen Files doch nicht auf dem cache?

[flinx01]

Tja, am liebsten alles ☺️, aber es reicht der Spindown. 

Ich habe gestern abend, das Docker Subsystem deaktiviert und siehe da, die Platten haben sich automatisch schlafengelegt.

Ich denke, das ein Docker dort noch aktiv ist (habe keine VM aktiv), sprich ich werde heute abend überprüfen ob ein Docker auf den HDDs und nicht im Cache aktiv ist.

 

Danke .....

[Ford Prefect]

...für S3 musst Du dann die HDDs des Cache-pools exkludieren, im S3 Plugin.

[flinx01]

Bingo: Übeltäter gefunden: mariadb in Kombination mit baikal. 

MariaDB legt seine Datenbanken unter /mnt/user/appdata/mariadb/databases/baikal ab, es gibt zwar die Freigabe appdate die den Status Ja:Cache hat, aber wie bekommt es das System mit den Datenbankdateien hin ? Ich vermute mal die liegen nie auf dem Cache, sondern immer auf der Datendisk, da ja immer nur neue Dateien auf dem Cache abgelegt werden. Die Datenbanken sind ja nie neu, sondern werden ja  von mariadb verwaltet. 

Deshalb wacht das Array auch alle paar Minuten wieder auf, da über baikal und einigen Clienten immer wieder der Status z. B. der Calender abgefragt werden.

Wie macht Ihr das mit DB Dateien ? Werden diese immer auf dem Cache gelegt und von von dort nur gesichert ? Wie ist das mit sehr grossen Datenbanken, z. B.  meine Photos (über 100.000) über digikam, alles auf den Cache und nur auf dem Cache ? Welche Erfahrungen habt ihr mit so etwas ?

Danke für jeden Tipp ...

Edited October 5, 2021 by flinx01

[alturismo]

8 minutes ago, flinx01 said:

Danke für jeden Tipp ...

daher gibt es hier geteilte Meinungen

 

cache only für /appdata anstelle cache prefer ... geschweige denn cache yes.

 

was kann bei dir passiert sein, irgendwann hat es bei dir die Daten verschoben und da diese jetzt im Dauerbetrieb laufen werden diese nicht mehr retour verschoben (wenn cache prefer läuft), da du jetzt sogar cache "yes" hast wurden deine Daten beim mover verschoben und bleiben auch da ... daher meine persönliche Empfehlung, shares wie /appdata und /system immer cache only, damit hättest du das erschlagen gehabt.

 

Les doch einfach mal bitte die Hilfe durch bei den shares, ist sauber beschrieben, kurz Gedanken machen was will ich, und dann sollte es klar sein.

 

Jetzt Docker aus, cache prefer setzen, mover starten (Daten sollten retour auf den cache verschoben werden), fertig.

 

Dann entscheiden ob cache prefer oder cache only DEINE option ist

[flinx01]

Jep, das hat funktionioert, die beiden appdata und system umgestellt auf cache prefer.

Seitdem läuft es wie es soll.

 

Danke alle die mir geholfen haben 😀

[mgutt]

On 10/5/2021 at 10:03 PM, alturismo said:

cache only für /appdata anstelle cache prefer ... geschweige denn cache yes.

Ich weiß, wir haben die Diskussion immer wieder, aber hätte er jetzt Only genommen, hätte er sich die Datenbank zerschossen und wir hätten den Fall wie in dem anderen Thread:

https://forums.unraid.net/topic/114553-system-freezes/?tab=comments#comment-1042206

 

 

Sag lieber verschieben+Only oder so.

 

 

 

 

 

[alturismo]

27 minutes ago, mgutt said:

Sag lieber verschieben+Only oder so.

 

zum reparieren hab ich prefer und mover vorgeschlagen, was willst du von mir ?

 

Grundsätzlich meiner Meinung nach immer noch ... diese shares auf prefer zu setzen und das Risiko eines moves einzugehen und dann die HDD's im Dauerlauf sind weil die Daten dann in use sind und nicht mehr retour gespielt werden und das wie hier beschrieben dann eintriit ... mit den aktuellen Möglichkeiten des movers diesen stündlich laufen zu lassen und per mover tuning dann sogar noch erst ab fillrate xy wirklich zu moven (um nicht permanent zu moven) ist "meiner Meinung" nach eleganter und hebelt dieses "künstliche" Risiko eines cache voll laufens aus ... außer ich will es erzwingen, aber da gibt es andere Möglichkeiten den Server zu crashen

 

Im Grundsatz ja egal weil beides sein pro und contra hat (wenn man will), aber hör endlich auf "meine Meinung" was ich auch so benenne zu berichtigen, Danke.

[mgutt]

8 minutes ago, alturismo said:

das Risiko eines moves einzugehen und dann die HDD's im Dauerlauf sind

Für dich ist es ein "Risiko", wenn die HDD läuft. Für mich ist Risiko, wenn der Container korrumpiert oder abschmiert. Wir haben hier irgendwie eine unterschiedliche Auffassung zur Bedeutung des Wortes "Risiko". Und ich argumentiere gar nicht mit einer theoretisch voll laufenden SSD, sondern mit dem Fakt, dass wir hier jede Woche User haben, die von der Grundeinstellung "Prefer" auf "Only" wechseln, weil sie das irgendwo gelesen haben und sich dadurch die Container zerschießen. Das hast du doch jetzt oft genug mitbekommen.

 

Und dein Argument den Mover stündlich laufen zu lassen, um ein Volllaufen der SSD zu verhindern, ist hinfällig, wenn der Nutzer schneller auf den Cache schreibt, also dieser auf das Array geleert wird, was denke ich mal bei den meisten so ist. Davon abgesehen, würde genau dieses stündliche Moven doch genauso bei "Prefer" greifen und das von dir "befürchtete" Laufen der HDD verhindern?!

 

Wobei ich das eh nicht verstehe, dass du so auf "Only" pochst, wo du deine Container doch eh schon alle auf "/mnt/cache" geändert hast. Die Cache-Einstellung hat dann gar keinen Einfluss mehr?!

 

13 minutes ago, alturismo said:

zum reparieren hab ich prefer und mover vorgeschlagen, was willst du von mir ?

Ja, im letzten Absatz. Angefangen hast du aber wieder mit "only anstelle prefer".

 

[alturismo]

9 hours ago, mgutt said:

dass du so auf "Only" pochst

ich poche nicht auf only, ich "epmfehle" diese shares auf only zu setzen, du pochst auf prefer ... das ist ein Unterschied

 

9 hours ago, mgutt said:

wo du deine Container doch eh schon alle auf "/mnt/cache" geändert hast. Die Cache-Einstellung hat dann gar keinen Einfluss mehr?!

korrekt, aber das hat ja nichts mit dieser Sache zu tun, da geht es um den overhead ...weißt du doch.

 

9 hours ago, mgutt said:

würde genau dieses stündliche Moven doch genauso bei "Prefer" greifen und das von dir "befürchtete" Laufen der HDD verhindern?!

vollkommen richtig

 

9 hours ago, mgutt said:

weil sie das irgendwo gelesen haben und sich dadurch die Container zerschießen. Das hast du doch jetzt oft genug mitbekommen.

ich bekomme oft genug mit dass appdata oder system Daten auf dem array liegen und alle am Suchen sind warum Ihre HDD's nicht in den Spindown gehen ... was in der Regel an cache yes liegt, jedoch auch mit prefer passieren kann, mit only erschlagen wäre ... und ich bekomme so gut wie nie mit das jemandem mal der cache voll gelaufne wäre und wegen only etwas passiert wäre dann bei system oder appdata. und wenn ich meine appdata und/oder system so vollschreiben würde dass die den mover schedule aushebeln, dann läuft eh grundsätzlich was schief .... also bleibt es meiner Meinung nach bei only als meine persönliche Empfehlung.

 

Es gibt für mich kein Szenario wo das irgendwie helfen würde etwas vorzubeugen, wenn ich Daten auf den cache schiebe dann reden wir doch über Medien etc welce ja nicht im /appdata oder /system share liegen, und da empfehle auch ich sicher nicht cache only ... und wenn ein docker in /appdata so reinschreiben würde, Bsp. emby transcoding nicht sauber konfiguriert, dann kann es knallen in solch einem Szenario, ob dann das moven der /appdata Dateien welche gerade nicht in use sind hilft und was dann passiert lasse ich einfach mal stehen.

 

9 hours ago, mgutt said:

Ja, im letzten Absatz. Angefangen hast du aber wieder mit "only anstelle prefer".

 

 

On 10/5/2021 at 10:03 PM, alturismo said:

Jetzt Docker aus, cache prefer setzen, mover starten (Daten sollten retour auf den cache verschoben werden), fertig.

 

Dann entscheiden ob cache prefer oder cache only DEINE option ist

 

mein grundsätzlicher Ansatz ist NICHT zu sagen was IMMER zu tun ist, sondern das soll jeder für sich entscheiden ...

 

On 10/5/2021 at 10:03 PM, alturismo said:

Les doch einfach mal bitte die Hilfe durch bei den shares, ist sauber beschrieben, kurz Gedanken machen was will ich, und dann sollte es klar sein.

 

 

sondern verstehen was da passiert und dann selbst entscheiden, da liegt der Unterschied zwischen uns beiden ... ich sage ja NICHT das prefer falsch ist, es gibt verschiedene Ansätze ... und die sollte man bitte auch respektieren solange es nicht grundsätzlich falsch ist.

[mgutt]

1 hour ago, alturismo said:

ich bekomme oft genug mit dass appdata oder system Daten auf dem array liegen und alle am Suchen sind warum Ihre HDD's nicht in den Spindown gehen ... was in der Regel an cache yes liegt

Ich supporte ja ständig Unraid Kunden und daher kann ich dir sagen, dass es zu 99% viel simpler ist. Die Leute verbauen ihre Komponenten, booten, richten das Array ein und nachdem sie ein Feeling für unRAID entwickelt haben, fügen sie einen Cache hinzu. Wenige von denen ändern überhaupt die Cache-Einstellungen und wenn sie es machen, dann auf "Only" und schon haben sie den Salat.

 

1 hour ago, alturismo said:

Les doch einfach mal bitte die Hilfe

Meiner Ansicht nach ist nicht das Problem, dass die Leute, die Hilfe nicht lesen, sondern dass unRAID es überhaupt ohne Warnung erlaubt von zb Yes auf Only zu wechseln, wenn von dem Share noch Dateien auf dem Array liegen.

 

Und Bezeichnungen wie "yes" sind auch unklar, sonst würden sie ja nicht missverstanden. Ich mein "ja, benutz den Cache" heißt für mich auch nicht "Nutze den Cache nur zeitweise".

 

Und dass man von "Yes" auf "Only" nur umstellen kann, wenn man vorher "Prefer" gewählt und den Mover gestartet hat, ist auch wenig intuitiv. Da ist also noch Luft nach oben.

[flinx01]

Uhps , ich  würde ohne DB Dateien ja alles auf Cache : JA stehen lassen, aber diese Einstellung führt dazu das das Array ununterbrochen läuft. Und zweitens nach der Erstanlage landen DB Dateien Permanent auf dem Array.

Aber: wenn auf Prefer , dann  sind diese permanent auf dem Cache, aber wenn der mover läuft dann transferiert der alle Daten auf das Cache,  richtig ? Wen  ja ist das eine Katastrophe, es würden z. B alle Datenbanken  überschrieben !

Ich habe  gerade den  Mover zur Sicherheit vollständig deaktiviert .... bis ich weiss was ich einstellen muss.

 

Soll ich die Datenbanken alle auf ein extra Laufwerk verschieben, so das Mover Aktionen ungefährlich sind ?

Für normale Dateioperationen ist das klar: alle betroffenen Freigaben auf JA.

Aber für alle Dateien , die ständig geändert werden  und DIE nicht bei jeder Änderung neuangelegt werden, ist eine Einstellung wie PREFER tödlich ...., weil die werden aus dem Array überschrieben ; Arghhh

 

Für mich heißt das , entweder alles auf  Cache : JA und ich vergesse das mit dem Stromsparen , bleibe also bei über 80 Watt oder ich lagere die Datenbanken aus......

 

Was aber bedeutet das Unraid Array Prinzip ist für Datenbanken ungeeignet , außer die Einstellungen NO oder ONLY

 

Habe ich das jetzt richtig verstanden ?

 

Ein etwas erschrockener Lukas 😳

 

 

Edited October 9, 2021 by flinx01

[alturismo]

12 minutes ago, flinx01 said:

Ein etwas erschrockener Lukas 😳

 

nicht erschrecken, kannst auf prefer belassen solange dein cache nicht voll läuft und die Dateinen auch gerade nicht in use wären, die 2 Szenarien müssten eintreffen dass der Mover verschiebt.

 

und cache "yes" wäre fatal (dann würder der mover verschieben was nicht in use wäre), cache "only" ist das was du sicherlich meintest (NUR auf cache egal was passiert).

 

Hilfe lesen ... wenn du das nicht verstehst, einfach gezielt nachfragem, dafür ist Sie da

[mgutt]

6 hours ago, flinx01 said:

wenn auf Prefer , dann  sind diese permanent auf dem Cache, aber wenn der mover läuft dann transferiert der alle Daten auf das Cache,  richtig ?

Der Satz macht keinen Sinn. Wenn sie permanent auf dem Cache sind, wohin sollte der Mover sie noch verschieben?

 

Und nein, da korrumpiert nichts, denn der Mover bewegt keine Dateien, die gerade in Verwendung sind.

 

Außerdem verweist bei Yes und Prefer der Pfad /mnt/user/sharename auf /mnt/disk*/sharename UND /mnt/cache/sharename. Es ist also egal wo die Dateien gerade liegen, die Prozesse können sie jederzeit laden.