October 4, 20232 yr Hallo, meine Festplatten schalten sich nicht in den Standby und ich finde die Ursache nicht. Auf dem Array liegen eigentlich nur Dateien, Docker und VMs liegen auf der Cache SSD. Wenn ich die primäre Festplatte in den spindown schicke, läuft sie sofort wieder an, das Gleiche bei der Paritydisk. Ich hatte schon das Plugin Dynamix Active Streams getestet, das zeigt keine geöffneten Dateien an. Ein zweites Problem ist, dass meine Win 11 VM extrem träge reagiert, wenn ich mich per RDP verbinde. Es fühlt sich an, als läuft die VM im Array oder mit hoher CPU Last, was aber beides nicht zutrifft. Vielleicht hängen beide Probleme irgendwo zusammen. Was soll ich posten, damit ihr mir helfen könnt? Welche Screenshots oder Diagnosedaten? Vielen Dank schonmal.
October 4, 20232 yr Solution 5 minutes ago, telly said: Docker und VMs liegen auf der Cache SSD. Ganz sicher? Prüfe mal ob du unter /mnt/user0 (=fuse mointpoint für das array) nicht doch "appdata" und "domains" liegen hast
October 4, 20232 yr Author Das ist nicht der Fall, dort liegen nur meine persönlichen Shares, die auf dem Array liegen sollen. Die Festplatten machen übrigens auch keinen Spindown, wenn alle VMs ausgeschaltet sind.
October 4, 20232 yr Author allerdings liegt dort auch das system share, mit dem docker.img und dem libvirt.img. Könnte das das Problem sein?
October 4, 20232 yr 1 hour ago, telly said: allerdings liegt dort auch das system share Das wird auf jeden Fall verhindern dass die HDD in spindown geht. Inwiefern das auch Einfluss auf die Performance hat kann ich allerdings nicht beurteilen. Aber "system" sollte eigentlich auf den Cache. Am besten einmal Docker Service(!) Und VM deaktivieren, system auf Cache prefer umstellen und den mover anschmeißen. Ggfs hinterher noch einmal prüfen ob auch wirklich alles verschoben wurde und dann die Services wieder anmachen. Die Docker musst du eventuell dann über Apps-> prevoiusly installed wieder hinzufügen. Aber Daten und Einstellungen bleiben erhalten
October 4, 20232 yr Author So, Docker und Libvirt.img sind verschoben und die HDDs gehen schonmal in den spindown, great! Aber die VMs sind wirklich noch grottig in der Performances dafür dass Win11 16 GB RAM und 8 CPU Kerne hat. Gibt es da noch Empfehlungen zum Optimieren?
October 5, 20232 yr 6 hours ago, telly said: Aber die VMs sind wirklich noch grottig in der Performances dafür dass Win11 16 GB RAM und 8 CPU Kerne hat. Gibt es da noch Empfehlungen zum Optimieren? die Treiber der libvirt iso sind installiert ?
October 5, 20232 yr Author Die Treiber von folgender ISO sind installiert: /mnt/user/isos/virtio-win-0.1.240-1.iso Der Gerätemanager ist sauber und zeigt keine Warnungen an. Die libvirt.IMG ist ja keine ISO und enthält soweit ich weiß keine Treiber für VMs!?
October 5, 20232 yr 2 hours ago, telly said: Die Treiber von folgender ISO sind installiert: perfekt 2 hours ago, telly said: Die libvirt.IMG ist ja keine ISO und enthält soweit ich weiß keine Treiber für VMs!? Nein, das passt, mein Fehler ... virtio-win-0.1.2xx-1.iso war gemeint ... ich bin aktuell bei 229 und keinerlei issues.
October 13, 20232 yr Author Habe aus anderen Gründen die Hardware meines Unraid Servers getauscht und eine neue VM aufgesetzt, jetzt hab ich das schnellste Windows, was ich je in den Fingern hatte
November 2, 20232 yr Ich stehe gerade vor dem gleichen Problem. Seit ein paar Tagen gehen meine HDD`s auch nicht mehr in Spin Down. Hab eigentlich alles was oben steht geprüft bzw. ausprobiert. Aber sobald ich eine Platte in Spindown schicke läuft sie wieder los. Gibt`s da noch irgendwelche Möglichkeiten das zu debuggen?
November 2, 20232 yr 1 hour ago, Sancho said: Gibt`s da noch irgendwelche Möglichkeiten das zu debuggen? das file activity plugin, aber meist ist es falsch konfigurierte Shares, Dockers, ... zeig mal den output von ls -la /mnt/user0 da sieht man schön was für Shares auf dem Array liegen, sollte /system, domains, /appdata, /iso da sein, prüfen ob das wirklich so sein sollte und was darin liegt.
November 2, 20232 yr Also ich hatte schon den Docker Service versuchsweise gestoppt, hat nichts geholfen. Die Shares wie system sind als Prefer : cache angelegt. Edit: was ich im Verdacht habe is der Symcon Docker mit dem Symcon Share, aber der Symcon Share ist als Cache eingestellt und wenn ich den Docker stoppe besteht das Problem weiterhin. Edited November 2, 20232 yr by Sancho Info vergessen
November 3, 20232 yr 7 hours ago, Sancho said: Die Shares wie system sind als Prefer : cache angelegt. auf welcher Unraid Version bist du denn ? heißt ja mittlerweile anders und da ist ja einiges ... vm's, isos, NC Data, Paperless, Timemashine, Homeassistant, ... eigentlich alles kann das Array wach halten als, File Activity Plugin mal schauen, ich schätze aber fast das wird dir einiges anzeigen ... vorher lesen wie es funktioniert und dann überlegen wie du dich einrichtest zum Thema Shares und wie die laufen sollen.
November 3, 20232 yr Also ich bin auf der Version 6.11.5 unterwegs. Laut File Activity ist eigentlich nur der Symcon Share aktiv. Die Einstellungen des Shares hab ich auch noch angehängt, sollte doch passen?
November 3, 20232 yr 11 minutes ago, Sancho said: Laut File Activity ist eigentlich nur der Symcon Share aktiv. und wie du siehst sind da Daten auf Disk1, und bei modify geht auch sicher die Parity mit an ... was ist jetzt die Frage "ob das passt" ... ja, prefer heißt auch dass Daten auch auf dem Array landen können und da laufen, nur wenn die in dem Moment wo der mover läuft nicht in Nutzung sind werden die retour auf den cache geschoben ... 12 minutes ago, Sancho said: Also ich bin auf der Version 6.11.5 unterwegs. dann wäre es langsam Zeit ... es gibt Gründe für Updates
November 3, 20232 yr Also Update hab ich jetzt mal gemacht auf 6.12.4... Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich. Hier nochmal ein paar Scrennshots nach dem Update Also eigentlich kann es nur an dem Symcon, den Docker habe ich vor einigen Tagen in Betrieb genommen. Aber alle Mountpoint gehen auf den Symcon Share, der ja Prefer : Cache ist. Und auch wenn ich den Container stoppe kann ich Disk 1 nicht in Spindown schicken, bzw fährt sie gleich wieder hoch.
November 4, 20232 yr Community Expert 3 hours ago, Sancho said: Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich. Hier nochmal ein paar Scrennshots nach dem Update Also eigentlich kann es nur an dem Symcon, den Docker habe ich vor einigen Tagen in Betrieb genommen. Aber alle Mountpoint gehen auf den Symcon Share, der ja Prefer : Cache ist. Und auch wenn ich den Container stoppe kann ich Disk 1 nicht in Spindown schicken, bzw fährt sie gleich wieder hoch. Ja, auf dem Cache wird gearbeitet und wenn man die Daten nicht mehr im stänidgen Zugriff braucht, verschiebt man/Mover die ins Array. Wenn man diese Daten dann im Array hat und diese wieder gebraucht werden, läuft natürlich das Array wieder (an). Deshalb sollte man genau prüfen, ob man die Ordner der Dockercontainer wirklich ins Array mit Festplatten verschieben möchte, sollte der Docker diese Daten dann sehr kurzfristig wieder anfordern oder gar manipuliert/ergänzen. Wenn Du also beispielsweise einen Text verfasst ist der Editor ein Programm, selbst wenn er ein Extramodul für Thesaurus oder so zusätzlich hat. Das Programm verwendet man ja öfters, das sollte also vielleicht mit all seinen Zusatzdateien im cache bleiben. Wenn Du den Text fertig verfasst, korrigiert, gedruckt und weitergeleitet hast, kannst und nicht mehr im Zugriff brauchst, dann kann der ins Array um ihn zu archivieren und vielleicht in 1 Jahr mal wieder zu lesen oder so. Du hast aber anscheinend die "modules" und "db" von Symcon verschieben lassen. Ich kenne die Software nicht (aber wenn mich eine Suchmaschine nicht in die Irre führt ist es ein Programmpaket zu Heimautomatisierung), aber wenn das Programm diese Modules/db wieder braucht, kann das Array nicht schlafen, weil das Programm da ja wieder drauf zugreift. Und wenn Symcon diese Dateien nicht nur lesend, sondern auch schreibend verwendet, läuft die Parity auch mit an. Sollte es wirklich etwas zur Heimautomatisierung sein, werden die *.csv Dateien vermutlich zu immer wieder beschriebenen Auswertungen/Statistikreihen und so gehören. Klar, daß die auf dem Array das Array nicht schlafen lassen. Nebenbei hast Du die Größe 0 kb für das Share eingestellt. Vielleicht überdenkst Du die Konfiguration nochmal, bevor Dir der Share voll läuft. Zu Deiner Annahme, daß Du mit Prefer alles richtig gemacht hast: dass der Mover da Sachen ins Array verschiebt, deutet darauf hin, daß es da wohl doch nicht passt. Stelle die Shares mal auf Cache only, stoppe Docker und lass den Mover laufen. Damit sollte alles zugehörende im Cahe landen, das Array davon befreit werden. Wenn Du dann den Docker wieder aktivierst sollte es auch ohne Array laufen. Wenn das Array dann immer noch nicht schlafen kann, schau weiter mit Fileactivity oder so nach, was da noch auf dem Array rumwerkelt und passe es an. Denn soweit ich es sehe hast Du auch system auf prefer... Eigentlich macht es (in meinen Augen) Sinn die unraid-typischen Standardshares alle auf dem Cache zu lassen. Vielleicht das iso Verzeichnis ins Array, da man davon ja nicht dauernd etwas installiert, aber ansonsten... ab in den Cache und dort belassen. Und wenn der Cache mit seinen rund 250GB zu klein ist: aktuell sind SSD Preise noch recht niedrig. Vielleicht sollte man mal 'nen Fuffi für eine größere SSD durchdenken? Größere SSD haben oft auch mehr TBW.... was sich gerade bei Anwendungen die ständig modifizieren/schreiben vielleicht auf die Lebenszeit positiv auswirkt? Edited November 4, 20232 yr by DataCollector Typos
November 4, 20232 yr 7 hours ago, Sancho said: Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich. kurz, das war falsch bei "Cache prefer", heute "Array > cache" diese Einstellung versucht die Daten auf dem cache zu halten, wenn es aber mangels Platz eng wird wird der mover jetzt anfangen Daten zu verschieben (auch die wo auf cache prefer stehen) damit der cache nicht voll läuft ... jetzt sind die erstmal im array. wenn jetzt wieder Platz ist beim nächsten mover run (1x täglich) wird der mover versuchen diese wieder retour zu schieben ... geht abr NUR wenn die Daten in dem Moment nicht in Nutzung sind ... sprich, wenn der Docker immer läuft (was ja meist der Fall ist) dann bleiben die im Array und du hast deine permanente HDD activity ... Du kannst jetzt folgendes versuchen, Docker Dienst stoppen, mover starten, jetzt sollten alle Daten die von Dockers sind der Share auf prefer steht retour gespielt werden da die ja frei sind ... dann Docker Dienst wieder starten und es sollte alles (erstmal) auf dem cache bleiben (solange Platz da ist). 3 hours ago, DataCollector said: Stelle die Shares mal auf Cache only, stoppe Docker und lass den Mover laufen. Damit sollte alles zugehörende im Cahe landen, das Array davon befreit werden. Wenn Du dann den Docker wieder aktivierst sollte es auch ohne Array laufen. ACHTUNG, wenn man erst auf cache only stellt dann moved der nichts retour weil das Array dem mover hier dann egal ist ... da ja cache only ERST moven, dann ggf. auf cache only umstellen ... um sicher zu gehen dass die /appdata auch immer im cache bleiben (heute kein secondary storage aktivieren)
November 4, 20232 yr @DataCollector@alturismo, ihr habt jetzt echt mal Licht ins Dunkle gebracht. Ich erkenne meinen Denkfehler, hatte da ein Brett vorm Kopf. Hab das Array vom Prinzip als Backup betrachtet, ist natürlich falsch... Also brauch ich den Share als Cache Only. Um das zu fixen würde ich jetzt folgendermaßen vorgehen wenn ich eure Posts richtig verstanden hab: 1. Docker stoppen 2. Share auf Array -> Cache umstellen 3. Mover laufen lassen 4. Secondary storage auf none 5. Docker wieder starten
November 4, 20232 yr Author Auch den VM Manager stoppen. Secondary erst auf none stellen, wenn alle Daten vom Array runter sind. Falls der Mover zu lange läuft, kann ich das Dynamix file Manager Plugin empfehlen, um die Daten zu moven.
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.