Jump to content

HDD S3 Sleep Modus


flinx01

Recommended Posts

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

Link to comment

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

Link to comment
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?!

Link to comment

So , ich habe alle Freigaben kontrolliert: 85632774_Bildschirmfotovom2021-09-2715-12-30.thumb.png.8c9e9b7189e3ee6349fe6e04e0d25b36.png

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

 

Link to comment

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

Link to comment

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

Link to comment

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

Ihc habe die Screenshots der Einstellungen angehängt.168291666_Bildschirmfotovom2021-10-0421-32-28.thumb.png.c8af1a03b91f8944e025962bd058a752.png1684964209_Bildschirmfotovom2021-10-0421-33-27.thumb.png.e5a42a3ab7f6e6ffeb010e7c8582ea13.png

 

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 :

918882821_Bildschirmfotovom2021-10-0421-29-15.thumb.png.b40c5dcc675a5f7e9e2be847e3329735.png

 

....

Link to comment
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?

Link to comment

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

Link to comment

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 by flinx01
Link to comment
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 ;)

Link to comment
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.

 

 

 

 

 

Link to comment
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.

Link to comment
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".

 

Link to comment
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.

Link to comment
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.

Link to comment

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 by flinx01
Link to comment
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 ;)

image.thumb.png.572979a5791b6673170aeb9113bd7ae4.png

Link to comment
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.

 

 

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